eth/protocols/snap: fix batch writer when resuming an aborted sync

[0xcb9ff9]

Description

upstream PR: go-ethereum#27842

Fixes ethereum/go-ethereum#27813.

The closure caused all subtasks to reference the same one batch when writing, so instead of each subtask of a contract growing and flushing it's own batch, they all grew the last one's, but flushed their own.

Interestingly however, this should only be an issue if there's also a lack of peers, otherwise whenever a delivery into the last batch is made, it should have flushed out everyone else's data too.

[DarianShawn]

Well, I guess it's a mistaken description of its issue.
Iterating map in golang will make a random sequence, if we use the map in a closure without assigning it. Then re-sequence happen, and something already iterated might iterate again.

I think we'd better provide some experimental data to support our conclusions.

[0xcb9ff9]

Well, I guess it's a mistaken description of its issue. Iterating map in golang will make a random sequence, if we use the map in a closure without assigning it. Then re-sequence happen, and something already iterated might iterate again.

I think we'd better provide some experimental data to support our conclusions.

The point is not iterate map, the for loop bug golang/go#56010

[DarianShawn]

Well, I guess it's a mistaken description of its issue. Iterating map in golang will make a random sequence, if we use the map in a closure without assigning it. Then re-sequence happen, and something already iterated might iterate again.
I think we'd better provide some experimental data to support our conclusions.

The point is not iterate map, the for loop bug golang/go#56010

Alright, I misunderstood the issue.

[DarianShawn]

LGTM