Interface LayerPullState

Local timestamp of the attempt, in milliseconds.

ok when the source answered and the run went to its end — even returning zero entities. partial when it wrote and stopped short. failed when the source said nothing usable.

🛑 partial IS THE MARKER'S RESUME POINT, and it is deliberately not a cursor. R9 made the pull commit page by page, so an interrupted run now leaves entities behind — durably. Persisting the unfollowed next link and restarting from it looks like the natural completion of that, and it is unsound: an OGC next link is an offset in most deployments, so a row inserted before it between two runs pushes entities past the window and they are never fetched, silently. That is the very defect this subsystem exists to prevent, reintroduced by the repair. What makes a re-pull cheap is not a cursor but idempotence — putManyPreservingLocal writes by identity — so the honest resume is: re-pull from the start, and let this marker say the last run did not finish.

Entities written during this attempt. Always 0 when outcome is failed.

The delta's starting point: the greatest freshness marker the last COMPLETE pull of a layer declaring offline.source.delta was served, kept as the server wrote it.

🛑 It describes what the store holds, so it goes when that content goes. A delta from it asks the source only for what changed since: valid only while the store still holds what the pull that set it wrote, for the same source and the same extent — hence scope. A purge of the store, a cut run, or a different scope means a complete pull next.

What mark was taken against — source, marker property and extent, serialised.

The source the run pulled from (../pull/source-key.ts). The entry is one per layer id and shared by every profile of the origin: it speaks only for a layer pulling from this same source, and a pull from another source replaces it. Absent on an entry written before 3.18.0, which speaks for every layer of that id, as before.