Task
parse_dig_local_flag and parse_chain_sync_flag (config.rs) fail OPEN on an unrecognised value — the exact defect just fixed in three sibling knobs under #282/#352. Decide whether that is correct for these two, and either fix them or record why they differ.
Why this is a decision rather than an obvious fix
The #282/#352 lane found and left them deliberately, with a stated reason worth engaging: both are default-ON knobs governing behaviour that does not reach the network, so failing open matches their own default. Failing them closed would turn a typo into a silently disabled local feature — arguably worse than the status quo.
That reasoning is plausible and may well be right. What makes it a ticket rather than a non-issue is that it has not been checked against what the flags actually gate. The sibling knobs were assumed harmless too, until one of them (DIG_PEER_NETWORK=OFF) was found leaving the peer network running because the match was exact-byte and the token was uppercase.
The test that settles it
Can either flag's behaviour reach the network, or change what a remote party can do? If yes, it is in scope and must fail closed like its siblings. If no, the fail-open is defensible — but then say so at the call site, so the next reader does not have to re-derive the distinction, and so a future change that gives the flag network reach has a comment to contradict.
Also worth settling in the same pass
Should these two adopt the shared off-token vocabulary regardless of failure direction? #282's fix unified three knobs onto one predicate. Two more knobs reading a different vocabulary is how the original defect arose — an operator who learns off works for three switches will reasonably expect it for all five. Vocabulary consistency and failure direction are separable decisions; make both explicitly.
Evidence
config.rs — parse_dig_local_flag, parse_chain_sync_flag. Surfaced by the dig-node#282/#352 lane, which recorded them as "worth a decision, not a silent change". That judgement is why this is filed rather than bundled.
Note the pre-existing narrowness this class hides behind: the existing peer_network_enabled test passed under both the old and new parser, because it listed only lowercase exact tokens and never a value the two disagree about. Any test written for these two flags must include a value the two candidate implementations would answer differently, or it proves nothing.
Acceptance
Each flag either fails closed on an unrecognised value, or carries a call-site comment stating why failing open is correct for it — plus a decision on whether both adopt the shared off-token vocabulary. Whichever way each goes, a test must distinguish the chosen behaviour from its alternative.
Task
parse_dig_local_flagandparse_chain_sync_flag(config.rs) fail OPEN on an unrecognised value — the exact defect just fixed in three sibling knobs under #282/#352. Decide whether that is correct for these two, and either fix them or record why they differ.Why this is a decision rather than an obvious fix
The #282/#352 lane found and left them deliberately, with a stated reason worth engaging: both are default-ON knobs governing behaviour that does not reach the network, so failing open matches their own default. Failing them closed would turn a typo into a silently disabled local feature — arguably worse than the status quo.
That reasoning is plausible and may well be right. What makes it a ticket rather than a non-issue is that it has not been checked against what the flags actually gate. The sibling knobs were assumed harmless too, until one of them (
DIG_PEER_NETWORK=OFF) was found leaving the peer network running because the match was exact-byte and the token was uppercase.The test that settles it
Can either flag's behaviour reach the network, or change what a remote party can do? If yes, it is in scope and must fail closed like its siblings. If no, the fail-open is defensible — but then say so at the call site, so the next reader does not have to re-derive the distinction, and so a future change that gives the flag network reach has a comment to contradict.
Also worth settling in the same pass
Should these two adopt the shared off-token vocabulary regardless of failure direction? #282's fix unified three knobs onto one predicate. Two more knobs reading a different vocabulary is how the original defect arose — an operator who learns
offworks for three switches will reasonably expect it for all five. Vocabulary consistency and failure direction are separable decisions; make both explicitly.Evidence
config.rs—parse_dig_local_flag,parse_chain_sync_flag. Surfaced by the dig-node#282/#352 lane, which recorded them as "worth a decision, not a silent change". That judgement is why this is filed rather than bundled.Note the pre-existing narrowness this class hides behind: the existing
peer_network_enabledtest passed under both the old and new parser, because it listed only lowercase exact tokens and never a value the two disagree about. Any test written for these two flags must include a value the two candidate implementations would answer differently, or it proves nothing.Acceptance
Each flag either fails closed on an unrecognised value, or carries a call-site comment stating why failing open is correct for it — plus a decision on whether both adopt the shared off-token vocabulary. Whichever way each goes, a test must distinguish the chosen behaviour from its alternative.