build(deps): bump the github-actions group across 1 directory with 6 updates#4
Open
dependabot[bot] wants to merge 9 commits into
Open
build(deps): bump the github-actions group across 1 directory with 6 updates#4dependabot[bot] wants to merge 9 commits into
dependabot[bot] wants to merge 9 commits into
Conversation
Ground truth from the keepalived IPv6 interop lab plus the address-owner source: the first IPv6 advert sources from the macvlan's transient EUI-64 link-local, not fe80::1, because iface.RegisterOwnedAddresses (address_owner.go) applies asynchronously -- the kernel installs fe80::1 on a later reconcile pass, after the first SendAdvert has already resolved a source. Reordering promoteToMaster to install-first was tried and proven ineffective (ordering cannot win an async race) and only churns the spec-annotated AC-3/R-4 order. Record the root cause and a do-not-retry warning; the behavior is cosmetic (both are valid RFC 9568 link-local sources, keepalived accepts both, election/failover/dataplane unaffected).
TestPeerTeardownWithdrawsSubscriberRoute and TestDeadPeerKeepaliveTeardownWithdrawsRoute called SetRouteObserver AFTER buildLogReactorWithClock had already started the reactor, so the test goroutine's write to r.routeObserver raced the run loop's read in notifyRouteObserverDown. -race reports it on the first run, not 1-in-3: reactor_setters.go:114 (write) vs reactor_kernel.go:263 (read). This is the test misusing the API, not a product bug. SetRouteObserver documents 'MUST be called before Start(); the goroutine creation barrier synchronizes the write here with reads in the run loop', and the sole production caller honours it -- subsystem.go installs the observer at :241 and starts the reactor 72 lines later at :313, the same discipline its neighbour comment spells out for SetKernelWorker. The lock-free write is deliberate: the reload-time setters (setHelloRetries and friends) DO take tunnelsMu because subsystem_reload.go calls them on a live reactor, while the install-time setters trade the lock for the Start() happens-before edge. Adding a mutex would weaken a working design to accommodate a misusing test. Fixed by giving the builder an observer parameter that installs before Start(), via buildLogReactorWithClockObserver; the existing 11 callers are untouched and the wrapper passes nil (a documented no-op). setHelloRetries stays after Start(), which is safe -- it locks. Verified: the two tests 5/5 under -race, and the whole internal/component/l2tp/... tree green under -race (was: race on run 1). make ze-lint-changed: 0 issues.
appliance-kernel-runtime failed with 'CONFIG_MACVLAN did not resolve to =y'. gokrazy/kernel/runtime.require gained CONFIG_MACVLAN for the VRRP macvlan work, but this test's fake docker kernel config was not updated to match, so enforceKernelRequirements rejected it (kernelreq.go:36 reads the require manifests at :41 and errors at :54 on any symbol that is not =y). The test file already documents exactly this coupling in the comment above the fake config: 'Adding a symbol to runtime.require (e.g. CONFIG_HUGETLBFS for VPP) requires adding it here too, or this test fails with <SYMBOL> did not resolve to =y'. This is that case; the fix is the one the comment prescribes. Worth noting for triage: run.sh does cd "$repo" and reads the WORKING TREE runtime.require, not the committed one. So this red reproduces against any commit you build while runtime.require is dirty, which is why it looked like a pre-existing failure rather than a consequence of the uncommitted VRRP change. Scope checked: appliance-kernel-runtime.ci is the only test carrying that fake config (sole file with CONFIG_VETH=y). kernel-wiring.ci also names --target runtime but only greps a make -n dry run, so it never enforces requirements. Verified: ze-test install --pattern appliance-kernel-runtime PASS; full install suite 37/37 PASS (3 environment skips).
TestInProcessChaosReconnect failed 3/3 in 92.00s with established==1. It
was logged as a -race flake ('passes 3/3 without -race'); it is neither
flaky nor -race-specific -- it fails identically in both modes, i.e. a
deterministic red, which plan/known-failures.md's own scope rule says
never belongs there.
Bisected (8 steps, git archive per commit -- git bisect needs a
forbidden checkout) to 44ad25d 'reconnect backoff floor 5s, not 120s'.
That fix is CORRECT and stays: it only changed WHEN ze lands in the
sleep below. The latent defect predates it.
A goroutine dump 30s into the freeze pinned the mechanism, after three
plausible theories (the new iface chaos weights; the blocking timer send
at virtualclock.go:168; 'the advance loop is slow') were each disproven
by experiment:
runner -> simWg.Wait() (runner.go:594) -- advance loop ALREADY
finished
ze session -> VirtualClock.Sleep (virtualclock.go:49) from
session.go:767
The advance loop costs what runner.go:427-430 implies -- 60s of virtual
time in ~0.6s real -- then exits, and nothing advances the clock again.
session.Run() polls for its connection with s.clock.Sleep(10ms)
(session.go:762-768), and VirtualClock.Sleep is a bare <-ch
(virtualclock.go:47-50): clock.Clock.Sleep takes no ctx, so simCancel()
cannot reach a goroutine parked there -- only Advance can. ze's session
was stranded mid-sleep, never finished the handshake, the simulator
blocked forever on the reply that never came (executeReconnectStorm ->
readMsg, simulator_actions.go:233), and simWg.Wait() hung until the
caller's 90s context tore the sockets down. Hence 92.00s, and
established==1 because the peer was asleep, not because reconnect was
broken.
Because the advance loop finishes in ~0.6s real, a chaos action firing
late in the virtual window is still mid-handshake when time stops. The
old 120s floor parked the retry outside the window and hid it.
Fix: advance the clock from a goroutine during teardown until both the
simulators and the reactor are down. Real time does not stop while a
system shuts down, and neither may virtual time. runner.go:370 already
warned that session.Run()'s handshake 'cannot complete until the virtual
clock advances'; that requirement just did not survive past the loop.
Verified: 3/3 PASS in 3.70s -- matching 3.69s measured at 8f5f2ff
(2026-07-08, pre-regression) vs 92.00s broken. Full ./internal/chaos/...
tree green; target test 2/2 green under -race. make ze-lint-changed: 0
issues.
parseBracketLeafList stored only the joined scalar mirror (tree.Set),
never the members (tree.SetSlice). Set writes t.values
(tree.go:141-152); SetSlice writes t.multiValues (tree.go:176-181);
GetSlice reads multiValues (tree.go:186-190). Different maps -- so
GetSlice returned nil for EVERY bracket leaf-list, and ToMap emitted the
joined text as one string. Consumers saw '[ a b ]' as the single value
'a b'. The sibling path storeValueOrArray (parser_list.go:414) always
did both; this one just forgot the SetSlice.
Proven, not inferred: the new test run against the unfixed parser gives
expected: []string{"foo", "bar", "baz"}
actual : []string(nil)
Reachable from real config, not just the hand-built schema:
yang_schema.go:319-322 builds a BracketLeafListNode for any leaf
annotated ze:syntax "bracket", and three modules use it --
ze-iface-conf.yang address (:266, :354), member (:608), allowed-ips
(:1004), sysctl-profile (:253)
ze-vrrp-conf.yang virtual-address (:54, :163) -- min-elements 1,
max-elements 16
exabgp.yang processes, processes-match
Two production consumers read those back as slices and got nil:
config/graph.go:339 (fam.GetSlice("address")) and
web/page_interfaces.go:157 (familyTree.GetSlice("address")). So an
interface unit could not carry two addresses -- ParseAddr saw the joined
"10.0.0.1/24 10.0.0.2/24" as one value. It stayed invisible because
every config in the tree used exactly one member.
Get() still returns the joined form, so the consumers reading the scalar
mirror are unaffected.
Verified: ./internal/component/config/... ,
./internal/component/bgp/config/ and ./internal/component/iface/ all
green with the fix; the new test FAILS on the unfixed parser (above).
9af30c4 fixed TestPeerTeardownWithdrawsSubscriberRoute but left its known-failures entry open -- exactly the stale-entry problem this file warns about, where a resolved red sends the next session hunting. Closes it, and corrects two claims for the record. It was NOT load-sensitive and NOT 1-in-3: -race reports the race on the first run, 3/3, alone and in the full package. And it was never a product bug -- SetRouteObserver documents 'MUST be called before Start()' (reactor_setters.go:106-109) and the sole production caller honours it (subsystem.go:241 installs, :313 starts). The original diagnosis and suggested fix were both right; only the severity and framing were off.
TestReactorKernelDisabledReturnsNil asserted require.Nil(t, teardowns) and had failed deterministically since e231fbf deliberately made the teardown drain unconditional. The assertion was stale, not the code -- the diagnosis in plan/known-failures.md was correct, and this is the fix it prescribed. Producer: collectKernelEventsLocked drains tunnel.pendingKernelTeardowns and nils the list BEFORE the worker check, then returns (nil, teardowns) when r.kernelWorker == nil (reactor_kernel.go:19-27). The drain is deliberately not gated on the worker so the route observer learns of torn sessions where no kernel worker exists -- the mechanism TestPeerTeardownWithdrawsSubscriberRoute depends on, i.e. the same teardown-withdraw path whose -race bug was fixed in 9af30c4. VERIFIED BY EXECUTION, not by reading. The file is _linux_test.go so it does not build on this macOS host (go test reports 'no tests to run'), which is why the entry sat open since 2026-07-10. Run in a golang:1.26 container -- the test is pure logic, no netlink and no privileges, so a container suffices: committed HEAD : FAIL reactor_kernel_linux_test.go:159: Expected nil, but got: []l2tp.kernelTeardownEvent{{localTID:0x66, localSID:0x9}} with the fix : PASS; full ./internal/component/l2tp/... tree green on linux/amd64 0x66/0x9 are exactly the event the test seeds, which confirms the producer above. The assertion is REPLACED, not dropped: a stricter require.Equal on the exact drained event plus a drained-list check, so the test now carries 4 assertions where it carried 3. The surviving assertions (setups nil, kernelSetupNeeded not cleared) were correct and are kept. Renamed to TestReactorKernelDisabledSkipsSetupsButStillDrainsTeardowns because 'ReturnsNil' now describes only the setups; leaving the old name would misdescribe the contract. Also closes the plan/known-failures.md entry. Like the chaos entry closed earlier today, this was a DETERMINISTIC red parked in a file whose own scope rule is non-deterministic failures only. Verified: make ze-lint-changed 0 issues; GOOS=linux go vet ./internal/component/l2tp/ clean (the darwin lint cannot see a _linux_test.go).
…updates Bumps the github-actions group with 6 updates in the / directory: | Package | From | To | | --- | --- | --- | | [actions/checkout](https://github.com/actions/checkout) | `4` | `7` | | [actions/setup-go](https://github.com/actions/setup-go) | `5` | `7` | | [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) | `6` | `7` | | [actions/configure-pages](https://github.com/actions/configure-pages) | `5` | `6` | | [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) | `3` | `5` | | [actions/deploy-pages](https://github.com/actions/deploy-pages) | `4` | `5` | Updates `actions/checkout` from 4 to 7 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v4...v7) Updates `actions/setup-go` from 5 to 7 - [Release notes](https://github.com/actions/setup-go/releases) - [Commits](actions/setup-go@v5...v7) Updates `astral-sh/setup-uv` from 6 to 7 - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@v6...v7) Updates `actions/configure-pages` from 5 to 6 - [Release notes](https://github.com/actions/configure-pages/releases) - [Commits](actions/configure-pages@v5...v6) Updates `actions/upload-pages-artifact` from 3 to 5 - [Release notes](https://github.com/actions/upload-pages-artifact/releases) - [Commits](actions/upload-pages-artifact@v3...v5) Updates `actions/deploy-pages` from 4 to 5 - [Release notes](https://github.com/actions/deploy-pages/releases) - [Commits](actions/deploy-pages@v4...v5) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/setup-go dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: astral-sh/setup-uv dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/configure-pages dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/upload-pages-artifact dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions - dependency-name: actions/deploy-pages dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the github-actions group with 6 updates in the / directory:
475767563545Updates
actions/checkoutfrom 4 to 7Release notes
Sourced from actions/checkout's releases.
... (truncated)
Changelog
Sourced from actions/checkout's changelog.
... (truncated)
Commits
9c091bbupdate error wording (#2467)1044a6dgetting ready for checkout v7 release (#2464)f028218Bump the minor-npm-dependencies group across 1 directory with 3 updates (#2462)d914b26upgrade module to esm and update dependencies (#2463)537c7efBump@actions/coreand@actions/tool-cacheand Remove uuid (#2459)130a169Bump js-yaml from 4.1.0 to 4.2.0 (#2461)7d09575Bump flatted from 3.3.1 to 3.4.2 (#2460)0f9f3aaBump actions/publish-immutable-action (#2458)f9e715ablock checking out fork pr for pull_request_target and workflow_run (#2454)df4cb1cUpdate changelog for v6.0.3 (#2446)Updates
actions/setup-gofrom 5 to 7Release notes
Sourced from actions/setup-go's releases.
... (truncated)
Commits
b7ad1dachore(deps): bump@actions/cacheto 6.2.0 (#771)0778a10Migrate to ESM and upgrade dependencies (#763)924ae3achore: bump version to 6.5.0 in package.json and package-lock.json (#762)e91cc3bBump@actions/cacheto 5.1.0, log cache write denied (#758)4a2405echore: update@types/nodeand@typescript-eslintdependencies to latest versi...78961f6chore: update@actionsdependencies and refresh license cache (#744)4a36011docs: fix Microsoft build of Go link (#734)8f19afcfeat: add go-download-base-url input for custom Go distributions (#721)27fdb26Bump minimatch from 3.1.2 to 3.1.5 (#727)def8c39Rearrange README.md, add advanced-usage.md (#724)Updates
astral-sh/setup-uvfrom 6 to 7Release notes
Sourced from astral-sh/setup-uv's releases.
... (truncated)
Commits
37802adFetch uv from Astral's mirror by default (#809)9f00d18chore(deps): bump zizmorcore/zizmor-action from 0.5.0 to 0.5.2 (#808)fd8f376Switch to ESM for source and test, use CommonJS for dist (#806)f9070deBump deps (#805)cadb67bchore: update known checksums for 0.10.10 (#804)e06108dUse astral-sh/versions as primary version provider (#802)0f6ec07docs: replace copilot instructions with AGENTS.md (#794)821e5c9docs: add cross-client dependabot rollup skill (#793)6ee6290chore(deps): bump versions (#792)9f332a1Add riscv64 architecture support to platform detection (#791)Updates
actions/configure-pagesfrom 5 to 6Release notes
Sourced from actions/configure-pages's releases.
Commits
45bfe01Merge pull request #186 from salmanmkc/node24d8770c2Update Node version from 20 to 24 in action.ymlcb8a1a3upgrade to node 24d560657Merge pull request #165 from actions/Jcambass-patch-135e0ac4Upgrade IA Publish1dfbcbfMerge pull request #163 from actions/Jcambass-patch-12f4f988Add workflow file for publishing releases to immutable action package0d7570cMerge pull request #162 from actions/pin-draft-release-verssion3ea1966pin draft release versionaabcbc4Merge pull request #160 from actions/dependabot/npm_and_yarn/espree-10.1.0Updates
actions/upload-pages-artifactfrom 3 to 5Release notes
Sourced from actions/upload-pages-artifact's releases.
Commits
fc324d3Merge pull request #139 from Tom-van-Woudenberg/patch-1fe9d4b7Merge branch 'main' into patch-10ca1617Merge pull request #137 from jonchurch/include-hidden-files57f0e84Update action.yml4a90348v7 --> hash56f665aUpdate upload-artifact action to version 7f7615f5Addinclude-hidden-filesinput7b1f4a7Merge pull request #127 from heavymachinery/pin-sha4cc19c7Pinactions/upload-artifactto SHA2d163beMerge pull request #107 from KittyChiu/mainUpdates
actions/deploy-pagesfrom 4 to 5Release notes
Sourced from actions/deploy-pages's releases.
... (truncated)
Commits
cd2ce8fMerge pull request #404 from salmanmkc/node24bbe2a95Update Node.js version to 24.x854d7aaMerge pull request #374 from actions/Jcambass-patch-1306bb81Add workflow file for publishing releases to immutable action packageb742728Merge pull request #360 from actions/dependabot/npm_and_yarn/npm_and_yarn-513...7273294Bump braces in the npm_and_yarn group across 1 directory963791fMerge pull request #361 from actions/dependabot-friendly51bb29dMake the rebuild dist workflow safer for Dependabot89f3d10Merge pull request #358 from actions/dependabot/npm_and_yarn/non-breaking-cha...bce7355Merge branch 'main' into dependabot/npm_and_yarn/non-breaking-changes-99c12deb21Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions