Scheduled transactions marked as Executed before actual execution begins

[joshuahannan]

Problem

When a block's system chunk processes scheduled transactions, the first system transaction (which invokes FlowTransactionScheduler) determines which transactions to execute, emits a PendingExecution event for each one, and marks them all as Executed at that point. The actual execution of each scheduled transaction happens afterward — still within the same block and collection — as the execution node reads those events and constructs individual transactions.

This creates a race condition: if any code in the same block queries getStatus() on a scheduled transaction after the scheduler system transaction has run but before that transaction has actually executed, it will see Status.Executed even though execution hasn't started yet.

Scope of the race condition

• Bounded to within one block
• A grace period of one block after the Executed status appears is sufficient to guarantee the transaction has actually run
• The scheduled timestamp does not reflect the actual execution block — a transaction may run later than its scheduled time due to congestion, so callers cannot reliably infer the execution block from the timestamp alone

Impact

• Any contract that checks the status of a scheduled transaction (e.g. for panic recovery / rescheduling) and does so within the same block the transaction is scheduled to execute may get a false Executed result
• Workarounds require adding a grace-period delay (checking N blocks after Executed appears), which adds fragility and complexity to callers

---

Proposed Fixes

Two implementation approaches, each with a cost:

Option A — Update status individually per transaction, inline during execution

• Status is set accurately at the moment each transaction finishes
• Con: makes concurrent execution of scheduled transactions impossible — the status update would have to happen sequentially after each transaction, eliminating any parallelism in the batch.
• Con: Still a potential incorrect status -- If a transaction fails, its status would not be updated to Executed, so in the same block and the following block it would still be marked as pending execution even if it failed, which would not actually be accurate and would be confusing to any code relying on correct status reporting.

Option B — Single trailing system transaction marks all as Executed after the batch

• Preserves parallelism across the batch
• Con: adds one additional system transaction per block This could slow the overall block rate and that trailing transaction cannot itself be parallelized

Key question

Which cost is worse: losing concurrent execution of scheduled transactions and correct reporting of failed transactions (Option A), or adding a fixed per-block system transaction overhead (Option B)?

---

Additional Notes

• Both changes are pretty easy from a Cadence perspective
• This is not currently blocking any major use cases — it requires more defensive code in callers to handle the edge case
• Any fix is expected to be a non-breaking Cadence contract change; existing scheduled transaction integrations should continue to work
• The PendingExecution event already intentionally emits an empty transactionHandlerTypeIdentifier (to avoid failures if the handler contract is broken) — this is unrelated but worth noting for anyone reviewing the system transaction logic

[joshuahannan]

@janezpodhostnik @j1010001 @holyfuchs @AlexHentschel

I created an issue here for discussion. Let me know if this summarizes the discussion well! Is someone already investigating the performance impacts of either option?

My preference would be to do option B because of the correct status reporting, but it isn't clear to me what the performance impact would be.

What do y'all think?

[holyfuchs]

Feels like option A would be the expected behavior, but I would assume the synchronization overhead is gonna be much larger than the additional system transaction.
For the ALP and YieldVault use cases either is fine.

[janezpodhostnik]

I think option A should be off the table because of the two problems that would require complicated solutions:

• no parallel execution (we would need to structure the on chain data in a way so we can get around this)
• if a scheduled transaction fails it cannot report its own status (this could only be changed with an FVM workaround specific to scheduled transactions)

However we did discuss another option in the meeting:

option C: instead of just having an executed status, we would have an executed at block status, that also holds the block height. (this way you can tell inside a scheduled transactions if a scheduled transaction its about to be executed in this block or was already executed in a past block)

[joshuahannan]

Patrick and I talked about that option already and that wouldn't work because we can't add fields in upgrades.

[janezpodhostnik]

can't add fields in upgrades.

If that is the only limitation for the solution we should consider that we might be able to use a migration to do it. It would be costly (not sure what would be involved), but it might be preferable to solution B.

[joshuahannan]

Can you explain why it might be preferable to solution B? What kind of costs would solution B have? I thought we typically try to avoid doing Cadence migrations unless it is fixing a critical bug