fixture

Overview ¶

Package fixture provides compiled helper processes for .ci scenarios.

Design: docs/guide/bfd.md -- the operator surface this fixture drives Related: plugin_fixture_03_bgp.go -- the non-strict bgp-bfd-opt-in fixture

The driver behind test/plugin/bgp-bfd-strict.ci. It starts ze with a peer whose bfd container carries `strict true`, and waits for the two log lines that say the whole path worked: the BFD plugin published its Service, and the BGP peer opened its BFD session with strict recorded on it.

The peer's remote address never completes a TCP handshake, so BGP never reaches Established. That is the point: draft-ietf-idr-bgp-bfd-strict-mode Section 7 says the BFD session opens "prior to the BGP FSM starting", so a strict peer that never connects must still open one, and a log line proving it could not be produced by the old on-Established path.

Design: docs/architecture/testing/ci-format.md -- independent OPEN sender facts Related: test/plugin/paths-limit-live.ci -- ordered wire assertions Related: ui_fixture_send_bgp.go -- the ephemeral SSH operator-CLI lifecycle

Design: docs/architecture/config/apply-ordering.md -- the ordered apply path Detail: ../../component/config/transaction/solver.go -- TopologicalSort, the order the swap driver observes Related: misc_fixture_shellports.go -- ifaceAddressSwapDriver, the single-interface renumber driver

The two drivers behind test/reload/config-apply-ordering-address-swap.ci and test/reload/config-apply-ordering-mixed-root.ci.

Both read the kernel's own netlink event stream through `ip monitor`. The order a transaction applied is not recoverable from the final state, and no function on the apply path writes one line per operation, so the event stream is the only place the order survives. It is what makes the applied ORDER a measurement instead of an inference from "the change landed at all".

Design: docs/architecture/config/apply-ordering.md -- a root with no decomposer Related: misc_fixture_shellports.go -- reloadSignalDriver, the shared rewrite-and-SIGHUP trigger Related: ../../component/config/transaction/orchestrator.go -- operationNodes, the coarse node this observes

The observer behind test/reload/config-apply-ordering-coarse-root.ci. It declares a config root no component decomposes, so the transaction represents it with one coarse node and applies it through the section apply. The line it prints on config-apply is what the test asserts: a participant the operation path leaves out receives no apply at all, and prints nothing.

Design: docs/architecture/config/apply-ordering.md -- the coarse node and its rollback Detail: ../../component/config/transaction/executor.go -- rollbackApplied, which skips a coarse node on purpose Related: register_config_apply_ordering_coarse_root.go -- the observer that proves a coarse node is applied at all

The two observers behind test/reload/config-apply-ordering-mixed-rollback.ci.

One refuses its section apply, which is how the test makes a transaction fail after a decomposed operation has already been applied. The other prints the line the test asserts on: a coarse node's participant is rolled back through the transaction-wide `config-rollback`, never through the per-operation rollback its SDK has no handler for.

Design: docs/architecture/api/architecture.md -- the initial-sync End-of-RIB barrier Related: plugin_fixture_09.go -- announceWithdraw09, the announce/withdraw observers for the same peer shape Related: plugin_fixture_01.go -- plugin01PeerCounter, plugin01RequireDone, the dispatch helpers used here

The fixture behind test/plugin/initial-sync-barrier-raw.ci. Registration lives in this file rather than beside the other bgp scenarios so the change touches no file another session is editing.

Design: docs/architecture/testing/interop.md -- a functional fixture drives the product's own dispatcher, so the .ci beside it asserts what an operator gets. Related: test/plugin/prefixsid-announce-rail-boundary.ci -- the frames this announce must produce for two eBGP peers that differ in one leaf. Related: internal/component/bgp/reactor/reactor_api_batch.go -- the announce rail the command reaches, buildBatchAnnounceUpdate.

Design: docs/architecture/rsvpte/mpls-rsvp-te.md -- RSVP-TE config reload (spec-mpls-10-rsvp-te-reload-completeness, closed 2026-09-05) Related: routing_fixture.go -- routingObserver, routingRows, the other rsvp-te scenarios Related: misc_fixture_shellports.go -- reloadSignalDriver, the shared rewrite-and-SIGHUP trigger

The two fixtures behind test/reload/rsvpte-reload.ci: the observer that reads `show rsvp-te interface` before and after the commit, and the trigger that rewrites the config and sends the SIGHUP.

Design: docs/architecture/config/transaction-protocol.md -- the participant protocol across a process boundary Related: register_config_apply_ordering_coarse_root.go -- the same shape for a root nothing decomposes

The observer behind test/reload/tx-protocol-external-plugin.ci.

It runs as its own process and declares the `bgp` root, which the iface and bgp decomposers do decompose. So one transaction carries both kinds of node: the decomposed peer operations the bgp root produces, and this plugin's coarse node. The line it prints is what proves the second kind crossed the process boundary, through `config-apply` rather than through the `config-operation-apply` its SDK has no default handler for.