The AutoCoder execution worker is recovered but deliberately remains quarantined. Readable work was preserved, ext4 was repaired and independently verified, and a bounded write test plus the NVMe short self-test passed. No runner has been returned to service because this is the second controller disappearance under runner load in two days.
AutoCoder development validation and delivery were expected to exercise the redesigned runner lanes after merge 570e4de22ac832514226e48c323b7fd1c3b55646 at 20:41 UTC. Shortly afterward, concurrent Actions jobs failed with Docker overlay input/output error and Read-only file system messages. The kernel reported NVMe write timeouts, failed controller resets, device disablement, an aborted ext4 journal, potential data loss, and a read-only remount of /dev/nvme0n1p1 at /mnt/runner-storage.
570e4de2 routes dev Rust, native, and WASM validation to the protected rust-delivery lane. The recurrence happened while the redesigned pipeline was active. Its workload may have exposed or accelerated the hardware fault, but there is no evidence that its workflow logic corrupted ext4.drg-k8s-worker-01.auth.home.lan./mnt/runner-storage, changed its fstab entry to noauto,nofail, and masked mnt-runner\\x2dstorage.mount./dev/nvme0n1p1 read-only with journal replay disabled (ro,noload).autocoder-engine/ and admin-tasks/, including Git metadata, while excluding only rebuildable build/container/cache paths./mnt/bigdata/recovery/drg-k8s-worker-01/2026-09-22-nvme-ext4/worker-readable-state.tarcb0683dc44b795f8b01f09aac57e25f55bbc284a85e6d5623483f32ef0956ac5.SHA256SUMS verifies the archive and all retained logs.e2fsck -f -n -v found orphaned/deleted Docker build inodes plus incorrect free-block and free-inode accounting.e2fsck -f -y -v replayed the journal and corrected accounting; exit 1 correctly indicated repairs were made. It reported zero bad blocks.e2fsck -f -n -v returned exit 0.SchedulingDisabled).Replacement of the NVMe and investigation of its PCIe/controller path are recommended before unattended service. If temporary use of this device is explicitly directed despite the repeat fault, restoration must be staged one runner at a time with live kernel observation; a successful SMART or bounded test must not be treated as proof that the hardware is reliable.
Recovery archive, manifest, checksums, SMART/error logs, pre-repair check, modifying repair, independent verification, self-test, and kernel storage log are retained under /mnt/bigdata/recovery/drg-k8s-worker-01/2026-09-22-nvme-ext4/.
Related prior record: /server-documentations/drg-k8s/changes/2026-09-21-worker-nvme-filesystem-recovery.