DataService.resetSignalKData() is private and has no callers anywhere in src/ — a repo-wide grep returns only its own definition (src/app/core/services/data.service.ts:265).
It is the only site that nexts _isReset, so isResetService() is a channel that never fires. That channel has a live-looking consumer: path-discovery.service.ts:80 subscribes to it and rebuilds its path index on emission, code that can therefore never run.
Found by four independent reviewers during the #579 review, each arriving at it from a different angle — the method now clears that PR's _metaBackfillAttemptsByPath as well, which is correct if reset is ever wired and inert until then.
Why it matters
Two things read as guarantees and are not:
- Any state cleared in
resetSignalKData is documented as being invalidated on a data reset. Nothing invalidates it. Everything in _skData and its siblings lives for the page load.
PathDiscoveryService looks like it recovers from a reset. It does not, because no reset is ever announced.
Neither is a live defect today — a WebSocket reconnect does not reset _skData either, so the caches stay mutually consistent. It is a correctness trap for the next change that assumes the reset path works.
Scope
- R1. Decide whether a data reset is a state Skip should have. The candidates that would want one are a WebSocket reconnect against a different server, and a profile switch that changes the connection.
- R2. If yes: call it from wherever that happens, and cover it with a test. If no: delete
resetSignalKData, _isReset, isResetService(), and the PathDiscoveryService subscription, rather than leaving a channel that reads as live.
DataService.resetSignalKData()is private and has no callers anywhere insrc/— a repo-wide grep returns only its own definition (src/app/core/services/data.service.ts:265).It is the only site that
nexts_isReset, soisResetService()is a channel that never fires. That channel has a live-looking consumer:path-discovery.service.ts:80subscribes to it and rebuilds its path index on emission, code that can therefore never run.Found by four independent reviewers during the #579 review, each arriving at it from a different angle — the method now clears that PR's
_metaBackfillAttemptsByPathas well, which is correct if reset is ever wired and inert until then.Why it matters
Two things read as guarantees and are not:
resetSignalKDatais documented as being invalidated on a data reset. Nothing invalidates it. Everything in_skDataand its siblings lives for the page load.PathDiscoveryServicelooks like it recovers from a reset. It does not, because no reset is ever announced.Neither is a live defect today — a WebSocket reconnect does not reset
_skDataeither, so the caches stay mutually consistent. It is a correctness trap for the next change that assumes the reset path works.Scope
resetSignalKData,_isReset,isResetService(), and thePathDiscoveryServicesubscription, rather than leaving a channel that reads as live.