我正在编写一个应用程序来从 Podio 获取应用程序的所有数据。代码正在发出此请求“/item/app/{appId}?offset={offset_val}&limit={limit_val}&sort_by=created_on”，以使用这些参数“offset_val”和“limit_val”从应用程序获取数据我正在获取数据500 个（跑道最多支持）个响应项。我所有的跑道应用程序都超过 20K。
代码正在运行并获取数据，对于一个请求，它会获取 500 个项目，在获取记录代码对其进行过滤后，并将其添加到数据库中，此操作需要 2-3 秒。当从应用程序中删除一个项目并且跑道将下一个项目位置向上移动时，案例失败，由于这种转变，我丢失了一些项目。
场景- 第 1 步：在任何请求中，我获取数据，假设请求偏移量为 1001，限制为 1500。 第 2 步：我获取了这些数据，并且我的代码可用于过滤和数据库操作。 步骤 3：在此间隔期间（过滤和数据库操作，或者可以说在下一个 Podio 请求之前），处理同一应用程序的某些用户从应用程序中删除了一项，并假设这是我请求中的第 1500 条记录。 （已收到该项目的挂钩，并且代码正在处理该项目） 步骤4：现在位置1500的项目已从跑道应用程序中删除，现在跑道将排列记录和项目，1501位置将取代1500（已删除的项目位置）。 步骤5：现在在数据库操作之后，我将再次触发一个偏移量为1501且限制为2000的请求。现在对于这个请求，我将错过该请求之前位于位置1501的数据（在步骤4中，第1501条记录）移至 1500）。 第 6 步：如果某些项目被删除，我的代码可以挂钩并删除这些项目。
但是我错过了移动位置的项目，并且移动后超出了偏移和限制范围。通过创建一个测试应用程序来测试这种筛选行为。
您能帮忙解决这个极端情况吗？
提前非常感谢。
我创建了一个测试应用程序并确认了此行为。
解决此问题的解决方案取决于跑道中项目删除的频率。
如果删除频繁：
如果在这两点之间删除了项目，则应在步骤 2 中调整偏移量，以便为可能重复的项目留出空间。例如，您可以调整偏移量以覆盖从500到1000的范围。此调整可确保您可以正确检查我们数据库中的第501项。如果它已经存在，您可以跳过它继续。否则，您需要相应地调整您的方法。
此外，我建议使用从 0 到 400 的偏移量，然后是 401 到 800，依此类推。这种方法可以提供足够的空间，并防止因最大化 API 限制而可能出现的潜在问题。