CheckLocalCompleteness (token/services/storage/db/common/checks.go) walks every confirmed transaction on each sweep and, for each one, rebuilds the token request, resolves its metadata, and re-derives the expected outputs. There is no persisted watermark of how far a previous sweep got.
With the default config (ScanInterval=1h, TransactionWindow=0, i.e. whole history), a node with a long transaction history redoes this parsing and crypto work for its entire history every hour, even though only the transactions since the last sweep are new. The cost grows without bound as the chain grows.
transactionWindow exists today as a way to bound this by wall-clock recency, but it trades away completeness: a history-walking check that never looks at an older transaction can't close findings for it, so narrowing the window isn't a free fix.
The real fix is a persisted "last verified transaction" watermark per TMS/role, so a steady-state sweep only does work proportional to new transactions rather than total history. That needs a storage-layer addition (schema + migration) across both the SQLite and Postgres backends, which is why it's being tracked separately rather than folded into an already large PR.
Raised during review of #2323.
CheckLocalCompleteness (token/services/storage/db/common/checks.go) walks every confirmed transaction on each sweep and, for each one, rebuilds the token request, resolves its metadata, and re-derives the expected outputs. There is no persisted watermark of how far a previous sweep got.
With the default config (ScanInterval=1h, TransactionWindow=0, i.e. whole history), a node with a long transaction history redoes this parsing and crypto work for its entire history every hour, even though only the transactions since the last sweep are new. The cost grows without bound as the chain grows.
transactionWindow exists today as a way to bound this by wall-clock recency, but it trades away completeness: a history-walking check that never looks at an older transaction can't close findings for it, so narrowing the window isn't a free fix.
The real fix is a persisted "last verified transaction" watermark per TMS/role, so a steady-state sweep only does work proportional to new transactions rather than total history. That needs a storage-layer addition (schema + migration) across both the SQLite and Postgres backends, which is why it's being tracked separately rather than folded into an already large PR.
Raised during review of #2323.