[thymikee]

Summary

Bounded batch/replay refuses resource operations before step effects. Nested typed refusal stops CLI and manifest retries after one attempt; ordinary resource-free failures still retry. Earlier progress and replay repair/resume remain. Ref #3325; dependent #3911 still requires its own integration and validation.

Exact head b920c2333b03031d3221a120b1040a6d9de9f8e2: 33 files, 1,923 gross lines from base. Its only change from a6fd is Linux apt setup diagnostics: ordinary output and UTC update/install stage markers. The six-minute limit, apt options, packages and failure exits remain. This identifies a future stalled phase; it is not a proven repair.

Validation

Exact clean b920 affected gate run-1vTiRz passed 834 related files/6,474 tests; fresh full Sol and Claude Sonnet workflow reviews found no findings. Runtime is byte-identical to a6fd. The a6fd exact gate, full reviews and Android live one-attempt/journaled-home/IME cleanup proof retain a6fd attribution; journal counts are not universal native-call counts.

The 56c0 and a6fd Linux apt setup attempts failed before smoke execution. One targeted 56c0 retry passed only 56c0. b920 CI completed: 17 success, one skipped, one neutral, including Coverage, Integration and all three platform smokes. SHA-attributed evidence. No merge or full #3325 completion claim.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-10-22 19:53 UTC

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	5.55 MB	5.54 MB	-13.0 kB
Package (unpacked)	5.55 MB	5.54 MB	-13.0 kB
Package (download)	1.68 MB	1.68 MB	-1.6 kB

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	42.8 ms	41.4 ms	-1.4 ms
CLI --help	88.0 ms	86.3 ms	-1.7 ms

[thymikee]

Linux Smoke failed before test execution: the “Install Linux desktop dependencies” step timed out after six minutes while running apt-get update/install. All later smoke execution steps were skipped. Failed job and logs.

This is a setup failure, not a smoke assertion. Source remains 56c0f477. GitHub initially rejected the job-only rerun while the containing workflow was active. After the workflow completed, GitHub accepted the single targeted infrastructure retry. No code or timeout changes were made. The original attempt remains failed; a repeat of the same setup failure will be treated as a finding.

[thymikee]

Verified actual head 56c0f4775ab67b5242f45172f23a534b7bf816d5: all 19 checks completed with 17 success, 1 skipped, and 1 neutral. The single Linux infrastructure retry passed, including dependency setup and smoke execution. Coverage, Integration, package/guards, CodeQL, and all three smoke lanes succeeded. No unresolved inline review threads were present.

Exact-head CI evidence and retry step results. The original timed-out attempt remains historical. Source is unchanged; no further retry, merge, approval, or label action was taken. Stacked #3911 is also green at 37c681c.

[thymikee]

Thanks for this. At 56c0f47 I found one problem that should be fixed before merge: a bounded nested test with retries re-runs a refusal that can never pass.

Take a batch step test flow.ad --retries 2, or a manifest with attemptDefaults.retries, whose script holds open …; click …; perf memory snapshot. admitBoundedTestRequest admits the suite, because it refuses only timeoutMs, recordVideo and manifest timeoutMs. Attempt 1 runs open and click, then the perf step is refused. The attempt outcome is marked infrastructure=false, because session-test-infrastructure.ts does not know this reason. So shouldStopReplayTestAttempts (replay-test session-test-attempt.ts:261) starts attempt 2 and then attempt 3. Each one repeats the mutating prefix and hits the same refusal. With a slow prefix, the retries can push the request into daemon_request_timeout, and the caller loses the typed refusal this PR exists to return. It also contradicts the claim that unsupported attempt settings are refused before starting. The rule: a bounded nested test never starts another attempt after a bounded_composite_resource_unsupported refusal. The smallest fix is to refuse flags.retries > 0 and manifest attemptDefaults.retries > 0 as test:attempt-retries in admitBoundedTestRequest, next to the timeout check that already reads the same manifests. Making the attempt outcome carry a typed terminal flag that shouldStopReplayTestAttempts honors would also work. Please add a routed test with a batch test step, retries=2 and a refused perf line, asserting one attempt and one prefix dispatch.

Not blocking, and you can take or leave these: withOriginalTestRefusalGuidance in test-command.ts:302 patches hints after the fact with untyped 'cause' in divergence probing, so the refusal hint now has three producers (lease-context.ts, session-replay-divergence.ts, and here), and one refusal factory could pick the public name from request ancestry instead; isBoundedCompositeRequest in lease-context.ts:33 probes for executionDeadlineMs and request-execution-scope.ts:320 excludes the literal names batch/replay, which is correct today but could come from the composite timeout policy registry; the same six-line hint assertion block is pasted in three tests (composite-resource-admission.test.ts:383 and :428, and composite-resource-admission-ime.test.ts:117) and could be one helper that asserts details.reason at its typed path; bindAndroidImeTestHost reaches callers through the unrelated ./snapshot-capture-fixtures re-export at snapshot-capture.fixtures.ts:7 and could have its own ./ime-host-fixtures export; and replay-e2e.md:21 could say that test stays unbounded and runs scripts with resource steps unchanged.

CI is green, with 19 checks passing at 56c0f47. The one earlier Linux smoke failure was the apt-get dependency step timing out before any test ran, which does not overlap this diff, and the targeted retry passed. There are no conflicts. I did not run the affected gate or the unit tests, and the 831-file / 6,458-test receipt is yours. I read the live Android evidence in your report but did not reproduce it. I also did not run a retries>0 nested test, so the repeated attempts come from reading the code. The logs and audio owner branches have unit coverage only, with no iOS or provider-device run. Once retries stop after a refusal and the regression test is in, I expect this to be ready to merge.

[thymikee]

I’m addressing the retry finding at the test-attempt owner, with a routed regression that counts attempts and prefix dispatches. The intended correction is to make a typed bounded-resource refusal terminal without removing legitimate retries for unrelated failures or changing direct unbounded tests. I’ll preserve the current heads/receipts as historical and validate/review the corrected head before pushing.

[thymikee]

Fixed on a6fd20a7577c4475bf64730db5e8e6dbaa4914a9. The nested attempt outcome now carries a typed terminal flag only when details.reason=bounded_composite_resource_unsupported; the retry scheduler stops after normal attempt cleanup. It does not classify the refusal as infrastructure or disable retries for resource-free failures. CLI retries=2 and manifest context retries=2 use the same route.

The routed, test-only negative on unchanged 56c0f477 observed three attempts and three home prefix calls for each variant. At a6fd, both variants assert one attempt, one prefix, the original typed reason/shape/public test name, dispatched:no, source line and no post-refusal capture. A resource-free ordinary failure still retries three times; direct unbounded test behavior remains. The exact a6fd affected gate passed 834 related files / 6,474 tests with unchanged checkout, and fresh full Sol and Claude Sonnet reviews found no concrete findings.

The intervening c080 gate failed on a provider fixture whose unscripted Android IME read depended on the helper artifact. The one-line a6fd test setup isolates that deadline scenario from IME activation; its four tests and the exact final gate passed. The failed receipt remains in the evidence ledger.

Android source/helper 0.21.31-dev live runs showed one attempt and one journaled home for each bounded CLI/manifest route, versus three attempts for an ordinary failure. IME returned to its original setting, and owned sessions/claims were cleared. Journal entries support the recorded prefix count, not a universal native syscall count. Full SHA-attributed evidence. New-head CI is pending.

[thymikee]

The a6fd Linux smoke attempt failed before tests ran: job 119976543593 again hit the six-minute “Install Linux desktop dependencies” timeout. All smoke execution steps were skipped.

This matches the initial setup failure on 56c0; its one targeted retry passed, but that historical result does not clear a6fd. I am treating the recurrence as an infrastructure finding and having the existing owner diagnose the workflow and successful/failed setup evidence. The quiet apt log does not establish whether update or install stalled, or whether the cause is networking or a lock. No further unchanged rerun, timeout increase, test suppression, or runtime-source change has been made.

b920 update (2026-10-22): Published workflow-only diagnostics at b920c2333b03031d3221a120b1040a6d9de9f8e2. The apt step now prints ordinary output and UTC update/install start/completion markers, with the same six-minute bound, options, packages and failure exits. Exact clean local run-1vTiRz passed 834 files/6,474 tests; independent full Sol and Claude Sonnet reviews found no workflow findings. Full b920 receipt, reviews, shell checks and diagnosis retain exact SHA attribution. The 56c0/a6fd setup failures remain failed; b920 Linux CI is pending. The apt cause is still unknown, and this diagnostic change is not a proven repair or a green smoke result.

[thymikee]

Thanks for the update. I reviewed a6fd20a and found no remaining code problems; the findings from the earlier review at 56c0f47 (#3910 (comment)) are now fixed. The only red check is Smoke Tests, which timed out in the Install Linux desktop dependencies apt step before any test ran. The diff touches no workflow or Linux desktop path, and the same setup timeout passed on retry at 56c0f47. Analyze (java-kotlin) and deploy-preview were still running when I looked. Before merge, please get a green Smoke Tests run on a6fd20a and let those two checks finish.

For evidence: I did not run the routed regression myself. I confirmed from reading the old shouldStopReplayTestAttempts and the outcome classifier that it fails without the fix. I did not re-run the affected-gate receipt or open the live-evidence gist, so the live evidence rests on your report at a6fd20a. The testIme: false line in composite-deadline.test.ts is test-only, and I did not check whether that test is environment-dependent on main.

[thymikee]

This PR is ready at b920c23. The earlier review of a6fd20a still stands, and I did not re-review the product diff beyond it. The new change only adds apt logging to the Linux workflow and drops -qq so apt output shows. I did not run the workflow. Smoke Tests and Analyze were still running when I looked, and the earlier Smoke Tests timeout was in the apt install step, which the product diff does not exercise. There are no conflicts. Before merge, Smoke Tests and Analyze need to pass on b920c23; if the install step stalls again, the apt timestamps will show which stage.

Not blocking: the apt diagnostics in .github/workflows/linux.yml share no code with the bounded-composite fix, so you can land them as a separate ci PR or leave them here and say so in the PR body. You can take or leave this.

[thymikee]

Exact published b920c23 now has all 19 checks completed: 17 success, one skipped and one neutral. Coverage, Integration, repository guards and Android/Apple/Linux smoke succeeded. Linux dependency installation and both smoke evidence steps ran successfully on this head. Raw exact-head CI and Linux step evidence. The older 56c0/a6fd setup timeouts remain failed historical evidence; this successful run does not establish the earlier APT stall cause. Corrected #3911 integration/live verification and full #3325 acceptance remain pending.