The number of queued changes can really get large if a node has been off for a while and then starts syncing millions of changes. One problem is that ever since we switched to in-SQLite bookkeeping almost exclusively, the logic is forgetful about which versions it has already seen to avoid storing too much metadata in memory.
Corrosion should propagate backpressure from the handle_changes loop so that synchronization stops if the queue reaches a certain length.
The number of queued changes can really get large if a node has been off for a while and then starts syncing millions of changes. One problem is that ever since we switched to in-SQLite bookkeeping almost exclusively, the logic is forgetful about which versions it has already seen to avoid storing too much metadata in memory.
Corrosion should propagate backpressure from the
handle_changesloop so that synchronization stops if the queue reaches a certain length.