Skip to content

[DX-3050] chip fanout router#21820

Draft
Tofel wants to merge 7 commits intodevelopfrom
dx-3050-chip-fanout-router
Draft

[DX-3050] chip fanout router#21820
Tofel wants to merge 7 commits intodevelopfrom
dx-3050-chip-fanout-router

Conversation

@Tofel
Copy link
Copy Markdown
Contributor

@Tofel Tofel commented Apr 1, 2026

This branch simplifies ChIP integration across local CRE and system tests by making Chip Router the single ingress entrypoint for workflow telemetry. Instead of having different tests reason about different ChIP paths, both lightweight test sinks and real ChIP / Beholder now sit behind the same router, which removes the old ingress ownership split and makes the topology much easier to understand.

Before this change, the ChIP path depended on the test. Most tests started their own test sink and, when running in parallel, relied on a programmatic fanout to avoid port collisions. A smaller set of tests used real ChIP / Beholder instead, with different startup, different ports, and different reasoning about where workflow events were actually going. That meant there was no single mental model for “how ChIP works in tests”, and understanding failures required knowing which path a given test had taken and how ingress ownership was being managed in that case.

It also meant that combining the two modes was awkward. If you wanted to run a test against the lightweight sink for assertions but also have real Beholder running so you could explore the same events in Red Panda, you had to work around ingress-port ownership manually. In practice that made “test sink for assertions + real Beholder for exploration” much harder than it should have been.

After this change, there is one ingress owner: Chip Router on 50051. Nodes always publish to that same entrypoint. Test sinks no longer pretend to be ingress owners; they start on ephemeral ports and subscribe behind the router. Real ChIP / Beholder also no longer competes for the ingress port; it runs downstream and subscribes through the same mechanism. The result is that the transport topology is the same regardless of whether a test uses a lightweight sink or the full ChIP stack, so the distinction between those modes is reduced to what the downstream consumer does with the events, not how telemetry reaches it.

That also makes mixed usage straightforward. A test can keep using its lightweight sink for assertions while real Beholder subscribes at the same time and receives the same event stream for interactive inspection. So one concrete benefit of this branch is that it becomes easy to use Beholder as an observability tool alongside normal sink-based tests, instead of treating those two modes as mutually exclusive.

It also turns Chip Router into standard environment infrastructure rather than a one-off extra. The router is now wired into normal environment startup, persisted in the main local CRE state, configurable through the env TOMLs, and managed like the other required images. That includes setup support, local image aliasing, runtime image override via environment variable, and updated docs in both chainlink and CTF so the architecture and operational flow match the code.

Before, the router path was operationally special: it had separate lifecycle handling, weaker setup guarantees, and more room for local drift between code, config, and docs. After this change, the router follows the same environment contract as the rest of local CRE. You can see it in the env TOML, set it up through env setup, override its image explicitly when needed, and rely on it being started as part of the environment itself rather than as an ad hoc side path. So the main gain is not just fewer port conflicts, but a more uniform, more composable, and much more explainable ChIP model across local development and tests.

Requires:

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 1, 2026

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

  • #added For any new functionality added.
  • #breaking_change For any functionality that requires manual action for the node to boot.
  • #bugfix For bug fixes.
  • #changed For any change to the existing functionality.
  • #db_update For any feature that introduces updates to database schema.
  • #deprecation_notice For any upcoming deprecation functionality.
  • #internal For changesets that need to be excluded from the final changelog.
  • #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
  • #removed For any functionality/config that is removed.
  • #updated For any functionality that is updated.
  • #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 1, 2026

✅ No conflicts with other open PRs targeting develop

@trunk-io
Copy link
Copy Markdown

trunk-io bot commented Apr 1, 2026

Static BadgeStatic BadgeStatic BadgeStatic Badge

View Full Report ↗︎Docs

@cl-sonarqube-production
Copy link
Copy Markdown

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