freenet/freenet-core

Observed live on the conformance capture peer, immediately after a restart on 38e905c2e: WARN freenet::conformance::capture: conformance capture retained nothing for this contract: its states exceed the per-state ceiling. Raise FREENET_CONFORMANCE_CAPTURE_MAX_BYTES to sample it. contract=9nrg6D16D2XjDjVvkSffQ1XWLjhuz8KaEWF9Q2CV4K7E refused_too_large=0 The message names the per-state ceiling as the cause and then reports zero refusals of that kind. One of the two is wrong, and a reader has no way to tell which. Cause reload() re-admits a bundle's states through the sampler and discards the result: for state in &bundle.states { sampler.observe_state(state); // Admission dropped on the floor } record(), the sibling path, counts the same outcome: if matches!(admission, Admission::TooLarge) { tracked.refused_too_large += 1; } So when a corpus is reloaded under a configuration whose per-state ceiling is smaller than the one that wrote it — which is exactly what happens wh

fdev wasm-runtime panics in clap before doing anything, on any invocation including --help. The subcommand is unusable in fdev 0.3.273. $ fdev wasm-runtime --help thread 'main' (1733173) panicked at /home/ian/.cargo/registry/src/index.crates.io-.../clap_builder-4.6.2/src/builder/command.rs:5066:18: Fatal internal error. Please consider filing a bug report at https://github.com/clap-rs/clap/issues note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace $ fdev wasm-runtime (same panic) command.rs:5066 in clap 4.6.2 is inside clap's own self-consistency debug assertions, which is where clap reports a malformed command definition — a duplicate argument id or long/short flag, a conflicting default, an unknown conflicts_with target, that class of thing. So this is very likely a defect in the wasm-runtime subcommand's derive/builder definition rather than anything in clap. Note the top-level fdev --help works fine, so it is scoped to this subcommand. Found while lo

Problem Nothing in this repo statically checks GitHub Actions workflow YAML. actionlint is not run in ci.yml or anywhere under .github/. That leaves a specific gap. The release path is substantially implemented in YAML — release.yml, cross-compile.yml, gateway-update.yml, release-announce.yml, binstall-smoke-test.yml — and the existing safeguards cannot reach errors in the YAML layer itself: scripts/release_canary_wiring_test.sh and scripts/release_mergequeue_test.sh pin workflow structure by scanning the files as text. They are good at "did the ordering silently regress", which is what they were built for. They do not execute the YAML, so they cannot evaluate an expression or resolve a reference. The shell suites extract run: blocks and execute them against fixture trees with cargo/curl stubbed. That validates shell logic, not workflow wiring. So this class ships unchecked today: a malformed ${{ }} expression a reference to a needs.<job>.outputs.<name> that does not exist a wro

Neither Windows CI job in .github/workflows/ci.yml runs the freenet library's --lib test target: Windows Check — cargo check --locked -p freenet -p fdev only (no --tests, so #[cfg(test)] code isn't even type-checked). Windows Service Unit — cargo build --locked -p freenet --bin freenet then cargo nextest run -p freenet --bin freenet --profile ci -E 'test(commands::service)', scoped to the --bin freenet target only. So a #[cfg(windows)]-gated unit test living in the library (e.g. wasm_runtime::module_cache::read_total_ram_bytes_returns_a_sane_value_on_windows, added in #5330) compiles and runs nowhere in CI — only on a real Windows box, manually. Flagged by this repo's own rule-review bot on PR #5330. Fix direction: add a Windows CI step running cargo nextest run -p freenet --lib (or extend Windows Service Unit's existing nextest invocation to also cover --lib, mindful of that job's own comment about first-run cold-cache compile time — see .github/workflows/ci.yml around the w

Problem main carries no CI signal for the expensive jobs. ci.yml skips them on pushes to main ("Skip expensive jobs on main push — PR already validated"), so NAT Validation, Simulation, Unit & Integration, Windows Service Unit and macOS Service Unit report skipped, not success, in every recent main run. The cost saving is real and the reasoning is sound as far as it goes. The consequence is not obvious, and it bit tonight: There is no baseline to compare a PR failure against. When one of these jobs fails on a PR, you cannot ask "is main also failing this?", because main never runs it. An infra flake is therefore invisible on main and lands on whichever PR happens to draw the bad runner — where it reads as that PR's fault. How it surfaced On #5303, NAT Validation went red. That PR's diff is shell, YAML and markdown only — no Rust. I checked main at the same base commit, saw CI success, and concluded the failure had to be specific to the PR head. That was wrong: the green did not i