Repository navigation
bug(push): investigate unexplained batch lifecycle failure #53
Description
Evidence
Main commit 6e24bcb, Debian run https://github.com/LucaLin233/Linux/actions/runs/34237080747: partial batch (good1 bad1 good2) entered lifecycle failure before good2 was scheduled. The next all-failure batch was blocked by the retained barrier; expected 2 failure records, got 0. Old assert_fail accepted any nonzero status and hid the first contract violation.
Current status
Root cause remains unknown. #51 merged as dc58996 strengthens exact status/flags/accounting assertions and eight consecutive rounds, without production wrappers or barrier resets. Its pre-merge full CI 34249483414 passed both environments. #52 addresses independently reproduced HUP substitution parsing failures, not a proven cause of this batch failure. Green runs do not prove resolution.
The user explicitly accepted deferring this unresolved anomaly. Do not treat it as fixed, or rerun unchanged jobs to hide a recurrence.
Next investigation
Capture the first internal failing boundary and lifecycle state before teardown. Preserve PID/start identity checks, cleanup grace, registration/session ownership validation and fail-closed barriers. No speculative production changes. Keep probes bounded and use CI, not production-host behavior tests.
Acceptance
Explain the causal failure path; add a deterministic regression or adequately justified targeted reproducer; verify both Ubuntu 24.04 and Debian 13 full suites without weakening assertions. See docs/push-batch-investigation.md and PR #51 review notes.
Activity
LucaLin233 commentedon Sep 8, 2026
Reassessment before project 4
Decision: stop active investigation for now and close as not planned, NOT as fixed. The user authorized closure if further investigation is not currently warranted.
Evidence reviewed: original Debian main run 34237080747 genuinely failed the partial-batch lifecycle contract; root cause remains unknown. Current main f9d5ed6 retains the exact status=1, lifecycle_failed=false, worker_error=false and accounting assertions introduced by #51. Latest main run 34259238142 passed both full 12-suite environments; each completed all eight consecutive partial/all-failure rounds. Recent main runs 34253827734 and 34255755951 also passed. The separate failure in 34251584749 was the command-substitution HUP control, not a batch reproduction.
Why no further active investigation now: available evidence has not isolated an actionable failing boundary or a targeted production correction. Repeating broad runs or introducing speculative production changes has low expected value. Existing assertions will fail on recurrence rather than accept any nonzero result, and failure diagnostics retain status/maps. This is a maintenance-priority decision with residual risk accepted, not proof that green runs eliminated the defect or that Bash substitution caused it.
Residual risk: a recurrence can stop unrelated transfers in a batch and leave a fail-closed barrier. It is not established to be harmless or environmental. Current diagnostics run after return and may miss the original pre-teardown state.
Reopen this issue if the exact lifecycle/accounting contract fails again, a user reports matching transfer interruption, or new evidence identifies a deterministic path. Capture commit, environment, first failing boundary and pre-teardown state; preserve ownership checks and barriers. Do not rerun unchanged jobs to hide failures.
No source, tests, workflow or production configuration changed during this reassessment. Historical evidence and docs/push-batch-investigation.md remain available; their pending-investigation wording is superseded by this triage decision.