igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

miner-faults register: the commits table and which side each class is on

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit 43cbec0d63)
This commit is contained in:
igneum-labs 2026-10-07 11:32:48 +00:00
parent 1506f6c003
commit c95e854265
1 changed files with 15 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
docs/plans/miner-faults.md
View file

@ -28,6 +28,21 @@ Standing rules behind every row (branch `miner-reliability`, off `release-0.3.19
| MF-7 | 7 Oct 2026, PC 1, 0.3.19 | Orphan `igneum-miner.exe` processes the app no longer tracked (two alive under `--stop-miners` with their rows at pid 0, one after) hammered the node's template RPC beside the tracked miners | The engine lost track of miners it had started (a stop that timed out, a restart over a live process) and never looked for them again | The engine owns every miner it started: at start, after every stop and every minute it kills any `igneum-miner` whose command line carries THIS engine's node RPC (the fence) and whose pid it does not track, one log line and one fault report per kill, never by name alone (`sweep_orphan_miners`, `platform::miner_processes`, `kill_pid`); a restart kills the slot's old process before the new one starts | injector step `orphan-miner` (a stray miner on the engine's node is killed inside the minute, the engine's own miner left alone) | `app-run orphan-miner PASS` |
| MF-3 | 7 Oct 2026, PC 1, Intel Arc | The Intel driver's first install did not bind: the device sat in Code 12 at install time; the card never mined until a reboot | A driver installed while the device reports a problem code (12, 43, 31) does not bind; nothing re-scanned the device afterwards, and the app only re-enumerates | The app re-enumerates every 60 s and starts the worker the minute the OS drives the card (`hotplug::diff` recovered / revived, `settle_new`); the row says what to do while it does not ("reboot with the card attached; if it persists, reinstall the driver with the card attached"); a Windows host asks for a re-scan (`pnputil /scan-devices`) after a problem code is seen, every 5 minutes, at most 6 times (follow-up, host side) | `hotplug` test `a_driven_card_that_turns_faulty_is_errored_and_recovers_later`; `app-run.mjs` step `card-appears` (a card listed after 2 minutes starts without a tap) | `app-run card-appears PASS` |
## Commits (7 October 2026)
| Repo | Branch | Commit | What |
|---|---|---|---|
| igneum | `miner-reliability` (off `release-0.3.19` db6f0964, with release-0.3.20's `igneum-pow` and master's build tooling) | `38a30397`, `c5cb5cd5` | the app side of every row, the register, the injector, the cards job kind, the LG-4 job, the CI check |
| igneum-node | `miner-reliability-20` (off `release-0.3.20-node` dc141409) | `f067f7c1` | MF-5's miner side: STATUS while waiting, identities from the template time, the fetch back-off |
Box lines: app tests 198 + 27 + 8 green on igneum-build-2 (the tree gate green, 33 checks on the Mac); igneum-miner 19
green on igneum-build-2; both Linux binaries built on igneum-build-1 (app sha256 6d4ee013, miner b3bf3590). Injector:
the pod run's lines are appended below when it ends.
Which side: MF-1, MF-2, MF-3, MF-4, MF-6, MF-7 and the cards kind are app-side (0.3.20's app). MF-5 is both: the
miner (the fork branch) prints the fields and caps the identities; the app reads them and keeps the worker. An app
without the new miner still gets MF-5's app half (a template timeout line is the heartbeat; the zero-rate clock holds).
## How a row is added
1. The day the class is seen: the row with Found, Class, Root cause. The rule, the test and the gate line the same day