You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Motivation
The task processor can call `process_actions` multiple times while a
previous batch's tasks are still in-flight.
When there's a backlog (`schedule.start` far in the past), the deadline
timer fires
immediately because the next event is also in the past. The
`last_requested_callbacks` guard passes, and
`next_actions` reads stale on-chain state (schedule.start hasn't
advanced yet), generating overlapping timestamps.
When both batches are eventually submitted as blocks, batch 2's stale
timestamps don't
match the now-advanced `schedule.start`, causing:
```
contract.rs:115: assert_eq!(timed_data.timestamp, next_timestamp, "unexpected timestamp in posted data")
```
## Proposal
Introduce an `in_flight_apps: BTreeSet<ApplicationId>` guard in the task
processor. When a batch of tasks is spawned
for an application, the app is marked as in-flight and subsequent
`process_actions` calls skip it. A new
`TaskMessage` enum replaces the raw `(ApplicationId, TaskOutcome)`
channel, adding a `BatchComplete` variant that the
spawned task sends after all outcomes. On `BatchComplete`, the guard is
cleared and `process_actions` is
re-triggered for that app so it reads freshly-updated on-chain state.
## Test Plan
- CI
- I had a stuck worker with a big backlog. After rebuilding pm-app with
this fix and restarting the worker with the new package version, I see
no more panics, and it seems that the worker is actually making progress
through the backlog:

0 commit comments