name: s-conf-oline-snap-flake description: ircd-common oline snapshot tests (s_conf_flags_snap + s_conf_find_oline_snap) flake under parallel load via a shared static-mut global; not a regression metadata: node_type: memory type: project originSessionId: 38f52265-0ab7-4fd0-bbbb-81e361f65a3c#

Under cargo test --workspace (heavy parallel load), ircd-common's s_conf_flags_snap::{oline_to_string_snapshot, round_trip_snapshot} intermittently FAIL with scrambled oper-flag letters (e.g. -→K, h→c, the flag string LKSClhdrRDeTqPpt→t). Run the binary alone → 7/7 pass; run it together with s_conf_find_oline_snap (the other oline binary) in a loop → fails ~1 in 5.

Why: both binaries exercise the same C-era static mut oline flag-conversion global in the ported s_conf; cargo runs the two #[test] binaries' threads in parallel and they race. Same class as [[p7-l1-shared-global-race]] and [[p5-s2s-stats-flake]] — a test-isolation artifact in the oracle crate, deleted at P12.

How to apply: when a --workspace run shows ONLY these two oline snapshots failing (scrambled flag letters, plus stray *.snap.new files), it is NOT a regression — re-run cargo test -p ircd-common --test s_conf_flags_snap alone to confirm green, delete the .snap.new files, and move on. Never "fix" it by accepting the scrambled snapshot. A leveva-only change cannot cause it (ircd-common does not depend on leveva).