A design question surfaced by the worker-readmission investigation, deliberately not relitigated inside that fix. Raising it with the measured evidence so it gets decided rather than inherited.
The behavior
With dashboard.tari_required: true — the default — a debounced Tari outage rejects workers: xmrig-proxy stops and every rig fails over to its backup pools. That is the long-standing node-down design, and the flag's documented meaning.
What the bench measured
The bench's dashboard log shows a continuous Tari gRPC outage (connection refused against the remote node) from 00:39 to 00:59 on 2026-08-04, with readmission at 01:01 — a 22-minute window in which the stack mined nothing at all, while monerod was healthy and 100% synced the entire time. p2pool keeps mining Monero through a Tari-leg outage (the merge-mine leg just pauses), so the counterfactual was: full Monero revenue, zero Tari revenue. The actual outcome was zero of both, with the hashrate donated to the rigs' backup pools. The same log shows Tari gRPC flapping again within the hour — on a remote-Tari deployment this is a recurring tax, not a one-off.
The question
For a merge-mining product, is "Tari down ⇒ stop mining Monero" ever the right trade? The rejection makes sense when mining is impossible (monerod down). For Tari it converts a partial-revenue state into a zero-revenue state, in exchange for… nothing the operator obviously wants. Three options:
- Flip the reject semantics only: a Tari-only outage never rejects workers;
tari_required keeps its other meanings (initial-sync gating, the full-screen sync view). Smallest change; splits one flag's meaning.
- Default
tari_required to false: one-line default change, but it also relaxes the sync-hold and UI takeover for everyone — a bigger behavioral shift than the problem needs.
- Keep as is, document the cost: defensible only if some deployment genuinely prefers not mining to mining-without-Tari, and none has been articulated.
Option 1 looks right from here: monerod-down keeps rejecting (mining is impossible), Tari-down keeps mining Monero and surfaces the outage through the existing Tari panel/alerts. The readmission side is already safe either way — a required Tari that has never been reachable can no longer hold workers off a healthy monerod.
Whatever is decided lands at tier 1 (the rejection decision table is fully unit-tested) plus a doc pass on the tari_required row, whose current text promises the present behavior.
A design question surfaced by the worker-readmission investigation, deliberately not relitigated inside that fix. Raising it with the measured evidence so it gets decided rather than inherited.
The behavior
With
dashboard.tari_required: true— the default — a debounced Tari outage rejects workers:xmrig-proxystops and every rig fails over to its backup pools. That is the long-standing node-down design, and the flag's documented meaning.What the bench measured
The bench's dashboard log shows a continuous Tari gRPC outage (connection refused against the remote node) from 00:39 to 00:59 on 2026-08-04, with readmission at 01:01 — a 22-minute window in which the stack mined nothing at all, while monerod was healthy and 100% synced the entire time. p2pool keeps mining Monero through a Tari-leg outage (the merge-mine leg just pauses), so the counterfactual was: full Monero revenue, zero Tari revenue. The actual outcome was zero of both, with the hashrate donated to the rigs' backup pools. The same log shows Tari gRPC flapping again within the hour — on a remote-Tari deployment this is a recurring tax, not a one-off.
The question
For a merge-mining product, is "Tari down ⇒ stop mining Monero" ever the right trade? The rejection makes sense when mining is impossible (monerod down). For Tari it converts a partial-revenue state into a zero-revenue state, in exchange for… nothing the operator obviously wants. Three options:
tari_requiredkeeps its other meanings (initial-sync gating, the full-screen sync view). Smallest change; splits one flag's meaning.tari_requiredtofalse: one-line default change, but it also relaxes the sync-hold and UI takeover for everyone — a bigger behavioral shift than the problem needs.Option 1 looks right from here: monerod-down keeps rejecting (mining is impossible), Tari-down keeps mining Monero and surfaces the outage through the existing Tari panel/alerts. The readmission side is already safe either way — a required Tari that has never been reachable can no longer hold workers off a healthy monerod.
Whatever is decided lands at tier 1 (the rejection decision table is fully unit-tested) plus a doc pass on the
tari_requiredrow, whose current text promises the present behavior.