release 0.3.14: the PC 2 rerun's upload failure, the suite accepted as run, the owed rows with owners to name
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
parent
39f4cf51e7
commit
1adeaf1dbc
1 changed files with 14 additions and 2 deletions
|
|
@ -66,7 +66,7 @@ deep-reorg rule, no snapshot floor, no loud flag file yet; its ETA asked at 16:4
|
|||
| The HiveOS package | `make-hive-package.sh` from the 934f393c Linux node and the 0.3.11 Linux workers, staged in `dl/public` for the ship's deploy | `igneum-hive-0.3.14.tar.gz` **c4699f2487580dcf06b5c22a36a2eb8383a3307b6137699c76c45eefebdd4c88** (24,659,507) |
|
||||
| The Windows run | `windows.yml` run 37501010655 on a90f6a5 (dispatched 17:06:50Z after the inputs push; the first dispatch 404ed under the flipped gh account); `ci` 37500950177 | both GREEN 17:13:24Z: `Igneum-Miner-Setup-0.3.14.exe` **08e75effc732f88bca11006b3b7cdf2bc533576f56819f79509fee47a8f5dd59** (45,416,619); `igneum-windows-app.zip` **1e0b0b96b79b9b74a633f2a66e375df6a33fcaa9df04b6a5d221166a6d90b310** (65,711,836), its igneumd.exe 44fa74c0... (the cross-build); fetched 17:13:46Z, not deployed. The 0.3.14 CI verdict: ci 37500950177 on a90f6a5; the Windows build 37501010655 on a90f6a5 (the tree is ac2d18d+, the packaged line and docs only since) |
|
||||
| The suites | the app tests and the six node suites with the igneum-pow feature on the Mac (17:08 to 17:11Z); the PC 2 build-and-suite job published 16:57:01Z on the 3.0 coordinator's word | the Mac: app 153 + 28 + 8; igneum-exec 19, igneum-miner 18, p2p-flows 33, p2p-lib 19, kaspa-pow 14, db_compat 7; kaspa-consensus 98 passed, 2 failed (the known M20 era test; the known flaky `ban_is_decided_by_the_carrying_block...`); consensus-core 107 passed, 1 failed (the fast-time file test, now "lacks the field exec_restart_hash": the dedup left the four exec fields out; a devnet-profile test, the proving agent's 0.3.14.1 item). PC 2 `build-20261006-165701` (16:57:31 to 17:03:58Z): both targets built, the app suite exit 0, the node suite exit 101 on the flaky finality test alone (`UnexpectedDifficulty` in the test's own chain setup; 97 of 98), the five other crates not run after it (the runner has no --no-fail-fast: a rule row, the runner carries it from the next cut); the coordinator's ruling: rerun with the list split, the flake recorded with a fix owner (its chain setup must build difficulty deterministically) |
|
||||
| The PC 2 rerun | the five crates that had not run (kaspa-consensus-core igneum-exec kaspa-pow igneum-miner kaspa-p2p-flows), node only, published 17:14:23Z | (pending) |
|
||||
| The PC 2 rerun | the five crates that had not run (kaspa-consensus-core igneum-exec kaspa-pow igneum-miner kaspa-p2p-flows), node only, published 17:14:23Z (job `build-20261006-171423`) | FAILED 17:25:31Z on "upload incomplete": both builds done (Linux 131 s, Windows), seven outputs uploaded, then the relay's blob service refused the final PUT (`service_unavailable`, "no url in the reply") and the test stage's result never reached the intake, so the rerun gave nothing. The coordinator accepted the suite as run: PC 2's consensus 97 of 98 with the flake recorded, the five other crates green on the Mac on the same node commit |
|
||||
| The Devnet 2 canary | the fleet agent's `tools/fleet/canary.sh` on six provers and two miners with 934f393c and the thirteen-field file, 10 minutes: zero rejected blocks, exec roots equal across the eight and the hub, paidSegments up on a prover, every node on the new version | (pending its PASS line) |
|
||||
|
||||
## 4. The rollout (to fill at the go)
|
||||
|
|
@ -83,4 +83,16 @@ unquoted `EXTRA_ARGS` with a space ran the flag as a command and the unit crash-
|
|||
the unit's user could not read a file under `/root` and the flag did nothing, silently. The PCs and the fleet's boxes stay at 0 until this
|
||||
cut or the same manual recovery (the fleet agent has the recipe; the PCs' app node takes no flag).
|
||||
|
||||
## 5. Owed
|
||||
## 5. Owed (the coordinator's rows, tonight, each with a fix owner to name)
|
||||
|
||||
| Row | What | Owner |
|
||||
|---|---|---|
|
||||
| The relay/job defect | the PC runner must retry a failed output upload (the relay's blob service refused a PUT at 17:25Z, `service_unavailable`), and the intake must report a partial job as FAILED with the stage that died, never as nothing (the rerun job showed no test result at all) | (to name) |
|
||||
| The flaky finality test | `processes::finality::tests::ban_is_decided_by_the_carrying_block_so_nodes_agree_on_every_voter_list`: its chain setup must build difficulty deterministically (`UnexpectedDifficulty` under load; fails inside full runs, passes alone) | (to name) |
|
||||
| The PC runner's `--no-fail-fast` | the test units run every crate even after a failing one (tonight the five other crates did not run after the flake) | the app's `jobbuild.rs`, next cut |
|
||||
| The fast-time file | `infra/fast-time/override-60x.json` deduplicated without the four exec fields (`exec_restart_number`, `_hash`, `_trust_daa`, `_state_root`): the devnet-profile test `fast_time_60x_file_is_the_devnet_at_60x` is the gate | the proving agent, 0.3.14.1 |
|
||||
| The playbook-quit allow entries | expire at 0.3.15 (the check fails the tree while they stand): the agg-cost scripts to `--stop-miners`, the Ember playbook rewritten | the aggregation-cost agent, the Ember agent |
|
||||
| Publish 2 | the fourteen-field object (digest 23e76936...), after Devnet 2 has crossed that exact digest move in the same order, never inside a rollout window; the miners first (the fleet by script inside one minute, then PC 1, PC 2 and the Mac on their clicks), the hands last | the next cut |
|
||||
| The wallet 0.1.5 | its final DMG on the 0.3.14 node, the clean-data-dir fresh-joiner check, the Windows question | `release-wallet-0.1.5.md` |
|
||||
| The gh account rule | every gh call switches to igneum-labs first and fails on any other active account (a CLAUDE.md row and the runbook's `gh_josh`) | this plan's runbook; CLAUDE.md to carry it |
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue