Skip to content

feat(cli): give an engine-gap verdict one fresh retry before it's final - #552

Merged
HappyDevs1 merged 1 commit into
feat/007-timing-race-repairfrom
docs/plan-autonomous-repair-loop
Sep 6, 2026
Merged

feat(cli): give an engine-gap verdict one fresh retry before it's final#552
HappyDevs1 merged 1 commit into
feat/007-timing-race-repairfrom
docs/plan-autonomous-repair-loop

Conversation

@HappyDevs1

Copy link
Copy Markdown
Collaborator

Summary

Stacked on #551 (timing-race handling) — this is PR 4/4.

Empirical testing against a real Fiori tenant found the repair loop's engine_gap verdict isn't fully reliable on ambiguous live evidence: the identical symptom (a wait target briefly resolving to empty text) got diagnosed as an unfixable engine gap once and a fixable timing race twice, across otherwise-identical runs. A verdict driven by one ambiguous read of a flaky moment was ending the whole record attempt immediately, with no second opinion sought.

  • record now treats an engine_gap verdict as provisional: it starts the entire flow over completely fresh (new driver session, new login) once before reporting a hard failure.
  • If the fresh attempt passes outright, the first failure was a one-off flake.
  • If it fails again, repair runs against the new failure as usual; if that also can't recover, both failures are recorded together in <flow>.repair.json as agreeing evidence of a real problem, not a coin flip.
  • A budget-exhausted verdict (repair genuinely tried several real fixes and none stuck) does not get this free retry — only a verdict that concluded no fix was worth attempting at all.

Verification status (honest note for reviewers)

Full workspace test suite green (only the pre-existing, environment-specific doctor_ai_e2e failure, unrelated). I was not able to directly observe the new code path fire live in this session — several fresh attempts against the real tenant all resolved cleanly or within the normal repair budget, none hit the engine-gap verdict again (the underlying flakiness rate is lower/more variable than the original sample suggested). Shipped on code review and clean fmt/clippy/test confidence rather than continuing to burn live attempts chasing a rare event; the retry's actual behavior will be fully visible in <flow>.repair.json the next time an engine-gap genuinely occurs in real use.

Test plan

  • cargo fmt --check
  • cargo clippy --workspace --all-targets -- -D warnings
  • cargo test --workspace — green except the pre-existing doctor_ai_e2e failure
  • Live confirmation of the fresh-retry path firing — not yet observed; see note above

Empirical testing against a real Fiori tenant found the repair loop's
engine_gap verdict isn't fully reliable on ambiguous live evidence: the
identical symptom (a wait target briefly resolving to empty text) got
diagnosed as an unfixable engine gap once and a fixable timing race
twice, across otherwise-identical runs. A verdict driven by one
ambiguous read of a flaky moment was ending the whole record attempt
immediately, with no second opinion sought.

record now treats an engine_gap verdict as provisional: it starts the
entire flow over completely fresh (new driver session, new login) once
before reporting a hard failure. If the fresh attempt passes outright,
the first failure was a one-off flake. If it fails again, repair runs
against the new failure as usual; if that also can't recover, both
failures are recorded together in <flow>.repair.json as agreeing
evidence of a real problem, not a coin flip. A budget-exhausted verdict
(repair genuinely tried several real fixes and none stuck) does not get
this free retry — only a verdict that concluded no fix was worth
attempting at all.

Verified: full workspace test suite green (only the pre-existing,
environment-specific doctor_ai_e2e failure, unrelated). Live
verification against the real tenant did not naturally reproduce the
engine-gap path in this session's attempts (the underlying flakiness
rate is lower/more variable than the original sample suggested); shipped
on code review and clean fmt/clippy/test confidence, with the retry's
behavior fully visible in <flow>.repair.json the next time it fires in
real use.
@HappyDevs1
HappyDevs1 force-pushed the docs/plan-autonomous-repair-loop branch from 5698825 to 9262bdb Compare September 6, 2026 20:32
@HappyDevs1
HappyDevs1 merged commit 161fd5a into main Sep 6, 2026
11 of 18 checks passed
@HappyDevs1
HappyDevs1 deleted the docs/plan-autonomous-repair-loop branch September 6, 2026 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant