VFX-D-1206¶

Title¶

RetryTimeoutPolicy

Explanation¶

A step declares verifyMode: RETRY but its polling window is not stated well. One code covers both halves of the same subject, told apart by the message:

• No timeout at all. The engine's own default bounds the polling window instead, so how long the step may wait is invisible in the suite. Nothing is broken; the budget is simply not written down where a reader can see it.
• A timeout above the advisory maximum. This server advises at most 300 seconds for a single polling step. A run that spends longer than that waiting on one assertion is past the point where a failure reads as "slow" rather than "hung".

The 300-second figure is this server's advisory bound, not an engine-enforced policy: the engine publishes no maximum today. It is stated explicitly here and in the finding's own message so it can never be mistaken for a rule the engine will enforce, and no verdict turns on it — the finding is a warning either way.

A timeout this server cannot parse produces no finding at all. Malformed durations are the schema pass's business, and a second differently-worded complaint here would be noise.

Common causes¶

• verifyMode: RETRY added to a step without adding the timeout that bounds it.
• A timeout copied from a slow CI environment (30m, 1h) into a suite that runs everywhere.
• A single step being used to wait out a long asynchronous process that would be better split across steps.

Fixes¶

• Add a timeout to the RETRY step — a duration string (30s, 2m) or a number of seconds.
• Shorten a timeout above 300 seconds, or split the wait so no single step owns the whole window.
• If the wait genuinely is long, consider whether the assertion belongs behind a different trigger (a webhook listener rather than a poll).