VFX-D-1209¶

Title¶

AsyncStepWithoutRetry

Explanation¶

A step whose type waits on work another system does is left on the default IMMEDIATE verify mode, so it asserts exactly once — against a result that has very likely not arrived yet. This is the classic source of a flaky end-to-end suite: it passes on a fast machine and fails in CI, for reasons that have nothing to do with the behaviour under test.

Which types count as asynchronous:

• mq-expect.* and webhook-listen.* — unconditionally. Both wait for another system to act.
• db-assert.* — only when an earlier step published to a broker (mq-publish.*). An ordinary read-your-writes assertion after an HTTP call is synchronous, and flagging every one of those would bury the finding that matters.

An explicit verifyMode: IMMEDIATE is reported just as an omitted one is: the assertion is polled zero times either way.

This is the only diagnostic in the semantic set that carries a machine-applicable fix.replacement, because it is the only one whose remedy is a single literal line with no authoring judgement in it. The replacement is the constant verifyMode: RETRY — spelled exactly as the schema's verifyMode enum spells it, since that vocabulary is case-sensitive.

Reported as a warning.

Common causes¶

• A message-queue or webhook assertion written like a synchronous HTTP assertion.
• A database assertion moved to run after a publish step without its verify mode being revisited.
• verifyMode omitted because the suite passed locally, where the broker happened to be fast.

Fixes¶

• Apply the offered fix: add verifyMode: RETRY to the step so the engine polls with bounded exponential backoff.
• Add a timeout alongside it so the polling window is written down — otherwise the engine's default applies and you will get VFX-D-1206.
• If the step really is synchronous in your topology, say so explicitly with verifyMode: IMMEDIATE and keep the warning as documentation that the decision was made deliberately.