docs(reliability): state the recovery-tap and WebDriver route rules, drop a deleted retry from a guarantee - #3090
Conversation
…drop the deleted retry from a guarantee
|
Size Report
Startup median (7 runs, lower is better):
|
There was a problem hiding this comment.
All reported issues were addressed across 2 files
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
…ibling-route fallback
|
This PR is ready at 7901a98. CI is green with 21 checks and none failing, and there are no conflicts. The diff is docs plus one string literal in a waiver reason, so I did not run tests or trace every writer to the dispatch ledger to prove the recovery-tap path never increments it. I also did not read the exact dispatched value set on the webdriver_route_unsupported error. Not blocking: the new sentence at https://github.com/callstack/agent-device/blob/7901a98/website/docs/docs/commands.md#L501 says a sibling-route refusal carries dispatched: no, but the final COMMAND_FAILED that orientation throws when both routes are refused has no reason and no dispatched, so the router stamps it unknown. The sentence is scoped to a single request's refusal, so the docs and code agree for that case. Landing the producer fix in its own PR is fine, and you can take or leave this note here. |
Summary
Three reader-facing statements the reliability arc (#3069) left unsaid or stale, each checked against the code on main
8c0edab4c7:commands.md, undererror.details.dispatched: an Android command that first dismissed a blocking system dialog or an ANR prompt reports as if that dismissal had not happened (a read staysno, a mutation keeps its own verdict); the dismissal is not a dispatched step. Source: ADR 0011 ("Android ANR and blocking-dialog recovery is outside the ledger") andRUNTIME_OPERATION_EFFECTS, which the recovery taps do not pass through.commands.md, same section: on a WebDriver device cloud, a driver that does not implement a route fails witherror.details.reason: webdriver_route_unsupportedanddispatched: no, and only a request that reads and changes nothing is ever resent. Source:webdriver-transport.ts(isUnsupportedRouteAnswer,IDEMPOTENT_METHODS,idempotentoverride) from fix(provider-webdriver): never resend a mutating WebDriver request #3070.interaction-guarantees.ts: theTAP_OUTCOME_NOT_OBSERVED_GAPwaiver still named "the no-change tap retry when the request setsinteractionOutcome.retryOnNoChange", a path fix(daemon): delete the no-change interaction retry path #3083 deleted (git grep retryOnNoChangeon main finds only this sentence). The clause is removed; the two remaining deferred marks are unchanged.Part of #3069. No behavior change.
Validation
pnpm typecheck,oxfmt --checkon both files,command-doc-coverage.test.ts,interaction-guarantees.test.tsandinteraction-contract-coverage.test.tspass.docs/agentsstays at 39,881 bytes (the budget is 40,000; this PR does not touch it).