Documentation / @etherfold/processor-entities / SYNC_CURSOR_KEY
Variable: SYNC_CURSOR_KEY ​
constSYNC_CURSOR_KEY:"lastSync"='lastSync'
Defined in: packages/processor-entities/src/cursor.ts:66
The key the neutral processor keeps its cursor under, on every backend.
One key, not one key per context ​
The state is keyed by {source, config, processor} and the obvious reading is that the cursor is keyed the same way. It is NOT, and the reason is load-bearing rather than an economy.
The core's discard path only fires when load RETURNS something whose context does not match (indexer.ts: the mismatch branch is inside if (loaded), and it is the branch that calls processor.clear()). A cursor keyed by context would answer "nothing stored" after a processor upgrade, load would return undefined, the core would start a fresh sync, and clear() would never be called: the previous processor's entity rows would still be sitting in the store, and the new run would index on top of them.
So there is ONE cursor and the context travels INSIDE it, where the core already validates it. Keying it would also imply a multi-tenancy the rest of the storage does not have, since entity rows carry no context and two contexts sharing a store would collide on rows long before they collided on a cursor.
This is why cursor.ts at the seam is careful to call the argument a KEY and not a context: the seam's key names WHICH cursor, and a ContextIdentifier is a different thing that happens to live inside the value.