Skip to content

fix(models): OR-group libp2p gossip dep; publish release/** images#297

Open
samcm wants to merge 3 commits into
masterfrom
fix/gloas-ci-and-stall
Open

fix(models): OR-group libp2p gossip dep; publish release/** images#297
samcm wants to merge 3 commits into
masterfrom
fix/gloas-ci-and-stall

Conversation

@samcm

@samcm samcm commented Jul 16, 2026

Copy link
Copy Markdown
Member

Moves libp2p_gossipsub_beacon_block into an OR-group with beacon_api_eth_v1_events_block in fct_block_first_seen_by_node and fct_block_proposer_head, so a stopped libp2p feed no longer stalls forwardfill. Both models froze on glamsterdam-devnet-7 when the gossip pipeline stopped publishing at gloas activation, while the beacon API sentries kept flowing.

Also adds release/** to the docker publish workflow branches. Per-devnet release branches (release/glamsterdam-devnet-7) get persistent image tags like release-glamsterdam-devnet-7, mirroring xatu's convention — the branch carrying the gloas ePBS models can then be pinned by devnet deployments without shipping those models to mainnet.

samcm added 2 commits July 16, 2026 14:46
libp2p_gossipsub_beacon_block is published by a pipeline deployed
independently of the beacon API sentries. When it stops (e.g. a sidecar
predating a fork's gossip changes, as happened on glamsterdam-devnet-7 at
gloas activation), fct_block_first_seen_by_node and fct_block_proposer_head
stall forever because it is a hard dependency. OR-group it with
beacon_api_eth_v1_events_block so the fresher source gates forwardfill.
Per-devnet release branches (release/glamsterdam-devnet-7) carry models for
raw tables that only exist on those devnets, so they cannot ship to mainnet
via master. Publishing branch-ref tags (release-glamsterdam-devnet-7) lets
devnet deployments pin them, mirroring xatu's release branch convention.
The OR-group lets forwardfill run at the fresher source's pace, so rows
from the slower source can land after their slot's interval was already
processed. Widen every data scan 90s behind the interval start so
subsequent tasks recompute the trailing slots with the fuller data;
ReplacingMergeTree(updated_date_time) keeps the newest version.

The window must widen every source uniformly - recomputing a slot from
a subset of sources would replace a complete row with a worse one. The
duty-completeness gate in fct_block_proposer_head keeps the exact
interval: its 12s-grid arithmetic assumes the scan window equals the
interval, and trailing slots were gated by their own task.
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