ENGINEERING NOTE 38 / 50 · CARD
Repair a deposit scanner without skipping the backlog
Resuming successful RPC calls is only the first step. Preserve the last confirmed cursor and distinguish catching up from being synchronized.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Check the rejected request
A node can enforce a smaller block-range limit than the scanner expects. Inspect the method and sanitized error, then test a smaller read-only range at the saved cursor. Do not reset the cursor to the chain head just to clear an alert.
Advance only after processing
Persist all relevant receipt events before advancing the cursor. Retain an overlap or other documented reorganization strategy and confirmations policy. A failure halfway through a batch should replay safely through idempotent receipt identities.
Monitor lag and freshness
A fresh last-success timestamp can coexist with days of backlog. Show head minus cursor and observed progress rate separately. Estimate catch-up time from measured net progress, accounting for new blocks, rather than declaring complete recovery after one successful request.
Illustrative implementation
end = min(safe_head, start + max_range - 1)
process_idempotently(get_logs(start, end))
commit_cursor(end + 1) # only after successful processingAcceptance check
Fail the second event in a batch and retry. Confirm no event is lost, no credit duplicates and the cursor does not jump over the failure.