What happens
Running the dig-node wallet out-of-service with a LOCALAPPDATA or DIG_WALLET_PORT override, the sidecar does not start — with no log line, no DB migration, no error. Silent.
It cost a lane two full node runs to notice, because every signal it had said things were fine.
Why it matters beyond one lane's afternoon
It makes the wallet effectively untestable out-of-service on a machine already running the node — which is every developer machine here, and the exact configuration anyone reproducing a wallet defect will be in.
That is a real cost: the wallet is where the $DIG balance lives, and the last six review rounds on #383 were all about balance correctness. A verification path that silently does nothing pushes people toward measuring against the installed service instead, where they cannot isolate a change.
Second, related finding — the same silence, one layer down
Structured logging fails silently for a non-admin run. Access is denied on C:\ProgramData\DigNetwork\logs, and it degrades to stderr rather than reporting.
So in a normal install, a wallet failure would leave no trace at all in the place an operator looks. The degrade is reasonable; doing it without saying so is not.
Scope
- Say why the sidecar did not start. A refused override, an unusable path, a port conflict — any of those is fine to refuse, but refusing silently is not.
- Report the logging degrade on the surface that still works, so "there are no logs" never means "logging failed to initialise".
- Consider whether an out-of-service wallet run is a supported shape. If it is not, say so and fail loudly; if it is, it needs to work on a machine where the service is already running.
Found while measuring dig-node#382's fix against the real wallet (PR#391).
What happens
Running the dig-node wallet out-of-service with a
LOCALAPPDATAorDIG_WALLET_PORToverride, the sidecar does not start — with no log line, no DB migration, no error. Silent.It cost a lane two full node runs to notice, because every signal it had said things were fine.
Why it matters beyond one lane's afternoon
It makes the wallet effectively untestable out-of-service on a machine already running the node — which is every developer machine here, and the exact configuration anyone reproducing a wallet defect will be in.
That is a real cost: the wallet is where the $DIG balance lives, and the last six review rounds on #383 were all about balance correctness. A verification path that silently does nothing pushes people toward measuring against the installed service instead, where they cannot isolate a change.
Second, related finding — the same silence, one layer down
Structured logging fails silently for a non-admin run.
Access is deniedonC:\ProgramData\DigNetwork\logs, and it degrades to stderr rather than reporting.So in a normal install, a wallet failure would leave no trace at all in the place an operator looks. The degrade is reasonable; doing it without saying so is not.
Scope
Found while measuring dig-node#382's fix against the real wallet (PR#391).