A deploy waits a grace for its build record before it is a mismatch

[fgurbanov]

A deploy now waits up to 300 s for its build record before counting as a digest mismatch; a false mismatch would raise a SEV item.

The hazard. Pipelines put maestro.build before maestro.deploy, but runtime-service's intake is a standard SQS queue, which doesn't keep order.

How it showed. runtime-service's first apply on the first tenant hit this: the intake's first batch failed because the workspace wasn't applied yet, so four events were retried. They happened to come back in order.

The fix.

• A deploy of a digest the ledger has never seen, younger than BUILD_GRACE_SECONDS (default 300), isn't recorded. The Lambda reports it as a batch-item failure and SQS retries it.
• The queue's visibility timeout (360 s) outlasts the grace. The retry then records it: built if its record arrived, a mismatch if not. T2 still holds, 5 minutes later.
• Over HTTP it answers 425 Too Early. A grace of 0 means no wait (the tests use 0 unless they ask).

Checks. runtime: 30 tests. New grace.test.ts:

• a young deploy gets 425 and records nothing;
• its build arrives and the retry records it, running with no signal;
• an old unseen deploy is a mismatch.

🤖 Generated with Claude Code