Skip to content

Unblock the weekly gates, refuse unsupported modes, and state the compatibility promise - #126

Merged
danielmarv merged 5 commits into
OpenElementsLabs:mainfrom
danielmarv:v1-readiness
Oct 13, 2026
Merged

danielmarv merged 5 commits into
OpenElementsLabs:mainfrom
danielmarv:v1-readiness

Conversation

@danielmarv

@danielmarv danielmarv commented Oct 8, 2026 •

Copy link
Copy Markdown
Collaborator

What this adds

Three changes that stand between 0.2.1 and a 1.0 release candidate.

The weekly Gates run is green again. Every scheduled run since 0.2.1 was BLOCKED, for two unrelated reasons:

  • SEC-FUZZ timed out without finding anything. Seven targets at 300 s each, plus the build, exceeded the gate's 30-minute timeout. The scheduled stage now gives all targets 30 minutes together, split evenly after building them, under a 45-minute timeout. A new target shortens each target's run rather than overrunning the gate. tests/fuzz-smoke.sh takes FUZZ_TOTAL_SECONDS; matrix version is now 2026.10.08-1.
  • The repository job named DOC-BOUNDARY and SEC-SECRETS, which the scheduled stage does not select, so run-stage.sh exited 1. It now selects from the plan as the rust and console jobs do.

Unsupported deployment modes are refused. server.mode = cluster or control now fails a new deployment_mode start-up check, which doctor also reports, unless server.unsupported_cluster_mode (RECORD_STORE_UNSUPPORTED_CLUSTER_MODE) acknowledges it. The acknowledged case is a warning. The cluster and node CLI commands are hidden from --help. Standalone deployments see one new passing check and nothing else.

A written compatibility promise. docs/reference/compatibility.md lists the covered interfaces and what a patch, minor and major release may change. It also covers the supported upgrade path, deprecation and which releases get fixes. The releasing guide defers to it, and the upgrading guide links it. The README no longer calls the audit chain "in development"; it shipped in 0.2.0.

What it deliberately does not do

  • No release. This does not bump the version. Once it is merged and a weekly Gates run is green, 0.3.0 follows as its own change.
  • Cluster code is not compiled out. A Cargo feature would be the stronger fence, but the API and server crates depend on the cluster crates throughout. Gating that is a refactor of its own, and a start-up refusal closes the accidental path now.
  • No new upgrade guarantee. The policy promises upgrades one minor release at a time, because that is what CMP-UPGRADE tests. Allowing skipped minor releases needs that gate extended first.

Limits a user needs to know

  • The acknowledgement flag is deliberately absent from the public configuration reference: DOC-BOUNDARY keeps clustering out of public docs. The compatibility page says undocumented settings are not covered.
  • The compatibility promise binds from 1.0.0. For 0.x it describes current practice.

Why it is built this way

  • Where the refusal lives. It is a preflight check, not a validation rule. Config::validate runs in config tests and in node join before the node starts. Preflight is where start-up already refuses machine-level conditions by name, so doctor reports the refusal with its remedy and nothing is opened first. I checked by hand: with RECORD_STORE_MODE=cluster the server exits before creating the data directory.
  • Why the opt-in is a config setting. The in-process cluster tests call record_store_server::initialize directly. A config field reaches them; an environment-only switch would not. The overlay contract tests cover the new variable.

  • cargo fmt --all --check
  • cargo clippy --workspace --all-targets --all-features -- -D warnings
  • cargo test --workspace --all-features --locked — 1117 passed
  • bash tests/rust-audit.sh — no new advisory or yanked crate
  • mkdocs build --strict, if documentation changed
  • bash tests/compatibility/run.sh, if the S3 surface changed — not applicable
  • CHANGELOG.md updated under ## [Unreleased], written for the person upgrading
  • Documentation updated in this pull request, not a later one
  • Tests fail without the change and pass with it
  • No pinned test value was copied from a failing assertion's output
  • No claim added that is stronger than what the code guarantees

Run locally: the affected crates' tests (record-store-config, -server, -cli: 159 passed), tests/gates/test_evaluate.py (20 OK), doc_boundary.py (PASS), and FUZZ_TOTAL_SECONDS=14 tests/fuzz-smoke.sh, which built once and ran all 7 targets for 2 s each. The first scheduled Gates run after merge is the real check of the new budget.

Seven targets at 300 s each, plus the build, exceeded SEC-FUZZ's 30-minute
timeout, so every scheduled gate run since 0.2.1 was blocked by a timeout
rather than a finding. The scheduled stage now splits 30 minutes across all
targets after building them, under a 45-minute timeout, and a new target
shortens each run instead of overrunning it.

The repository job also failed every scheduled run by naming two gates that
stage does not select. It now runs only the gates the plan selects, as the
rust and console jobs already do.
Cluster and control modes ship in the binary but are unsupported and outside
any compatibility promise. A stray mode value put a deployment on that footing
without anyone choosing it. Start-up and doctor now fail the deployment_mode
check unless server.unsupported_cluster_mode acknowledges it, and the cluster
and node CLI commands are hidden from --help.
Compatibility and Support lists the covered interfaces, what each kind of
release may change, the supported upgrade path, deprecation, and which
releases receive fixes. The releasing guide now defers to it, and the README
no longer calls the shipped audit chain in development.
SEC-AUDIT-NPM started failing on new high-severity advisories against
next 16.3.7 (six, all fixed in 16.3.8), sharp 0.35.4 and source-map-js
1.2.1. Next.js and eslint-config-next move to 16.3.8; sharp and
source-map-js move to their patched releases within existing ranges.
SEC-AUDIT-RUST started failing on three new high-severity RustSec
advisories (RUSTSEC-2026-0338, -0340, -0343) against quinn-proto 0.11.17,
which reqwest pulls in through quinn. All are fixed in 0.11.18;
Cargo.lock now resolves 0.11.19.
@danielmarv
danielmarv merged commit a71db41 into OpenElementsLabs:main Oct 13, 2026
19 checks passed
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