Repository navigation
chore(deps): bump pulseengine/rivet from 0.40.0 to 0.41.0 - #312
Closed
dependabot[bot] wants to merge 1 commit into
Closed
dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [pulseengine/rivet](https://github.com/pulseengine/rivet) from 0.40.0 to 0.41.0. - [Release notes](https://github.com/pulseengine/rivet/releases) - [Changelog](https://github.com/pulseengine/rivet/blob/main/CHANGELOG.md) - [Commits](pulseengine/rivet@v0.40.0...v0.41.0) --- updated-dependencies: - dependency-name: pulseengine/rivet dependency-version: 0.41.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
|
temper did not enable auto-merge: breaking update pulseengine/rivet 0.40.0 -> 0.41.0 needs a human review. |
avrabe
added a commit
that referenced
this pull request
Oct 21, 2026
#284's compliance job has failed every run since 2026-09-08. The cause in the first failing run's log (run 34174312781, job 101900580327) is not what the issue and the earlier PR body claimed: thread 'main' panicked at rivet-core/src/export.rs:1700:45: byte index 26 is not a char boundary; it is inside '—' (bytes 24..27) of `Lightweight DSSE verify — extract dsse off the 179-crate wsc tree` rivet 0.3.0 byte-slices a title to truncate it during HTML export, and artifacts/dev/features.yaml:669 gained an em dash. The step that dies is **Export HTML report** — Install Rivet succeeded ("rivet 0.3.0 (ec747593 HEAD 2026-03-22)") and Validate passed, because 0.3.0 does not enforce the status enum. So the correlation with dependabot's 2026-09-01 action bump (0.32 -> 0.35) was spurious: the trigger was a new artifact title, landing on a binary frozen since March. `rivet-version:` is the rivet BINARY the compliance action downloads, and it sat at v0.3.0 while the action tag advanced to v0.40.0. Both pins now move to v0.41.0, which supersedes #312. Verified locally against this store: `rivet 0.41.0 export --format html` -> "Exported 553 pages", exit 0, no panic. The input cannot simply be dropped so dependabot moves both together: its default is "source", which runs `cargo build --release -p rivet-cli` in the CALLER's workspace — correct inside rivet, fatal here. The pin froze for six months because nothing watched it, so the second half of this commit is a watcher. `claim-check` gains a `captures-agree` evidence kind — N hand-kept copies of one value, each the first capture group of a pattern, must be equal — and claims.yaml binds it to the four pin sites. Three negative controls, each run and recorded: * drifted pins (action v0.40.0 vs binary v0.39.0, this branch's state before the fix) -> RED, naming both values and both files, exit 1; * one copy deleted -> RED via `min-captures` (3 < 4), so the gate cannot go quietly vacuous when the string it watches disappears; * glob matching no files -> RED ("measures nothing"). Positive control: all four sites at v0.41.0 -> 5/5 claims hold, exit 0. It runs in Claim Check, the only PR workflow with no paths filter. Every future dependabot rivet bump will now go red there until `rivet-version:` is edited to match. That is the intent. What this does NOT fix, stated plainly: * The compliance job will still be red, now at Validate instead of Export. `rivet validate` exits 1 on this store — 22 errors locally, and 31 in CI because `../synth` cannot exist in a single-repo checkout, so cross-ref checking is skipped there and 9 synth links are counted as broken. The action's run_validate.sh (rivet #953) propagates that exit code. Closing those 22 is separate work. * No release was ever blocked by this. `build-and-release` needs only `build-native-cli`; nothing in release.yml depends on `build-compliance`. That is why v0.11.0 shipped from a red release run. What #284 cost us is the compliance *evidence*, not the artifacts. * This gate, like every other check here, is advisory: main's `required_status_checks.contexts` is empty and the repo has no rulesets, so nothing stops a merge over a red board. Also drops `.claude/settings.json`: enabling a plugin for the repo is a real change but not this PR's, and an unrelated file riding along inside a CI fix is how REQ-27's 1,721 insertions landed under a 13-line commit title. Refs #284 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH
avrabe
added a commit
that referenced
this pull request
Oct 21, 2026
…ICAL (REQ-31), lands #307 Lands #307 and REQ-31 together, as a merge commit so each of the six commits keeps its own message. Squashing a stack is what buried #301's security fix inside #305 and REQ-27's 1,721 insertions under #273's 13-line title. ## The 9.3 CRITICAL is retired, not excepted `cargo audit` measured today with a freshly fetched advisory database and the workflow's own ignore list: main 31 vulnerabilities, exit 1 wasmtime 47.0.4 (the MSRV-1.94 ceiling) 18 vulnerabilities, exit 1 this merge 0, exit 0 wasmtime alone was 20 of the 31, quinn-proto 5, rustls 4. Eight advisories stood against 47.0.4 — RUSTSEC-2026-0327 (9.3 CRITICAL) plus -0353, -0354, -0356, -0357, -0361, -0378 and -0316, most published mid-cycle — all fixed only in 48.0.4+/49.0.x. Staying inside MSRV 1.94 could clear nine of 31 and no more, which is why the toolchain bump stopped being deferrable cleanup. NOTE: the first commit's message says "cargo audit goes 12 -> 3". That was a week-old DB snapshot and is wrong in both directions; the table above is the measurement. Corrected on #284 and in the v0.12.0 CHANGELOG. Shipping under a documented exception was available — wasmtime is optional and not in `default` — and was declined. The two `--ignore` lines are deleted rather than re-justified, and `Cargo Audit` is green in CI for the first time this cycle. Also cleared: RUSTSEC-2026-0382 (rustls-webpki) and -0381 (webpki-roots), both certificate-verification, both published within 48 hours of the release, both landing on step 1 of `PinnedCertVerifier::verify_server_cert`. ## What re-qualifying the gates actually found The scope said "record each masked gate's status before/after". The before was the finding: measured from pre-mask exit codes in the run logs rather than API conclusions, **four of five Kani modules were masked and seven harnesses were failing behind a green board** — while `formal-verification.yml`'s own summary comment claimed three ran unmasked, contradicting the matrix three lines below it. That false claim had already propagated into the rivet store and the v0.12.0 CHANGELOG. All three corrected; `claims.yaml` gains `KANI-MASK-RATCHET` so the masked count can shrink but not grow. Then the bump turned `Witness MC/DC gate` red, and reading the gap rows instead of re-pinning the number found that on macOS/1.96.1 **the gate measured nothing and reported OK** — the `^src/` scope collapsed to zero decisions, so the "below baseline" branch printed a notice and exited 0. Empty scope is now a hard error. The +2 on linux is `wasm_module/mod.rs:455` becoming visible, not lost coverage: witness's own suggested row is infeasible for a short-circuit `&&`. Baseline recalibrated 3 -> 4 with all four host/toolchain measurements recorded, and a 6-case verdict table proves a further regression still trips it, so the recalibration did not buy green by disarming the gate (#318). Fixing that gate then exposed `.gitignore`'s `*.sh`, which had silently dropped the new gate script — `git add -A` skipped it without a word and CI failed with exit 127. `bash foo.sh || true` would have been green. The vacuous-oracle gate now asserts every `bash <path>.sh` a workflow runs is a tracked file, and `rust.yml` finally lists `verification/**`, so the gate is no longer scoped to everything except itself. ## Re-qualification: before and after, from the logs Pre-mask exit codes and harness counts, read from the run logs because the API reports a masked step as success. Before: main @74665d9b, run 38971394138, rustc 1.94.0. After: this branch @35b8316c, run 39607181505, rustc 1.96.1. gate before (1.94.0) after (1.96.1) Kani varint 5/5, exit 0 UNMASKED 5/5, exit 0 Kani merkle 2 ok / 3 fail of 5 2 / 3 of 5 identical Kani dsse 0 / 1 0 / 1 identical Kani format 2 / 2 of 4 2 / 2 of 4 identical Kani wasm_module 0 / 1 0 / 1 identical Verus (both steps) exit 1 exit 1 identical Rocq exit 1 exit 1 identical Witness MC/DC 2 gaps, baseline 3 4 gaps, baseline 4 UNMASKED 3 decisions in scope **The bump changed nothing behind any mask.** Every masked module carries the same pass/fail counts on both toolchains, so the seven failing harnesses predate it and none is new. That is the result the masked-gate accounting existed to produce — "green before, green after" could not have shown it. The calibration comment in witness-gate.sh lists two in-scope decisions for linux/1.96.1; the log counts three. The third is `varint.rs:29`, FullMcdc, 0 gaps — the count and the verdict are unaffected. Recorded here rather than fixed by another push, which would have restarted the full board. ## Also `RUST_VERSION: "1.90.0"` deleted from three workflows — nothing ever read it. `examples/wasmtime-loader/Cargo.lock` is now committed (#274), without which raising the example to wasmtime 49.0.4 would not stay fixed. **MSRV for consumers: the `runtime` feature now requires rustc >= 1.96.** Closes #274 · Implements REQ-31 · Refs #284, #302, #312, #316, #318 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH
Contributor
Author
|
Looks like pulseengine/rivet is up-to-date now, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/github_actions/pulseengine/rivet-0.41.0
branch
October 21, 2026 22:23
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
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 pulseengine/rivet from 0.40.0 to 0.41.0.
Release notes
Sourced from pulseengine/rivet's releases.
... (truncated)
Changelog
Sourced from pulseengine/rivet's changelog.
... (truncated)
Commits
c15754achore(release): v0.41.0 (#1092)555bd59ci: nightly mutation sweep as 64 rivet-core shards plus 16 rivet-yaml shards ...7b8dc5fci(release): publish musl Linux assets beside the gnu archives (#1086)28f3146fix(cli): rivet add --field coerces mapping/sequence values; validate catches...b24baa6build(deps): wasmtime 48.0.6 clears RUSTSEC-2026-0353..0364 (#1091)27c8c33test(yaml): the lexer's document-end marker arm is tested (#1082)9cd0858build(deps): rustls 0.23.46 clears RUSTSEC-2026-0346..0349 (#1089)734cad0feat(yaml)!: rivet owns its YAML parser and emitter; serde_yaml removed (REQ-...2c83276fuzz: a null HIR link target is a finding only when serde accepts the input (...81dfc30fix(yaml): an empty link target fails validate on both paths, not only --dire...Dependabot 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 this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)