Skip to content

Clean up vid generation#6420

Open
lutter wants to merge 3 commits intomasterfrom
lutter/vid-gen
Open

Clean up vid generation#6420
lutter wants to merge 3 commits intomasterfrom
lutter/vid-gen

Conversation

@lutter
Copy link
Collaborator

@lutter lutter commented Mar 4, 2026

The way vid's were created was very brittle and relied on passing a counter around in the right places. We encapsulate this logic in a SeqGenerator that can be shared freely for the duration of a block and makes sure that generated vids are unique

@incrypto32 I am asking for your review mostly for the first commit which affects vid generation proper
@isum I am asking for your review mostly for the second commit which changes amp subgraphs

lutter added 2 commits March 4, 2026 15:48
Replace the per-EntityCache vid_seq and seq fields with a shared
VidGenerator backed by Arc<AtomicU32>. Created once per block and
cheaply cloned across all EntityCache instances, this eliminates VID
collisions in ipfs.map() callbacks and offchain triggers without
manual sequence threading.
The AMP runner previously created an EntityCache with a fake
SeqGenerator(0) and shared it across block boundaries, even though an
EntityCache should always be tied to a single block. Now only the
LfuCache is threaded through, and EntityCache is created locally in
process_record_batch_group with the correct block's SeqGenerator.
@lutter lutter requested review from incrypto32 and isum March 4, 2026 23:53
Add a unit test that simulates the ipfs.map() pattern (multiple
EntityCache instances sharing one SeqGenerator) and verifies VIDs are
sequential. Extend the file_data_sources runner test so that two
offchain triggers in the same block each create an entity, exercising
the shared VID generator end-to-end.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant