feat(results): record the environment knobs and declared config a run actually used

[fcostaoliveira]

Rescoped after review. This lands the environment-knob half of #212. The resolved index params (m, ef_construction, the qdrant HNSW diff) are split to #273, which carries Closes #212. Two of #212's four minimum-viable knobs — number_of_shards and the retry budgets — land here; m and ef_construction do not, so this is Refs #212.

Merge note: commit e5f4f02's trailer still says Closes #212 and is superseded by ab31500. Please don't carry it into a squash message.

origin/master (#263) is merged in, not rebased onto — the branch is already published and the standing rule here is to add a commit rather than force-push. Squash-merging collapses it either way.

The problem

A result file recorded the configuration name and nothing else. No collection_params, no upload_params, none of the ~104 environment knobs the engines read, and not even --host. On origin/master, four runs differing in REDIS_QUERY_TIMEOUT and in which server they hit produce this, four times, byte for byte:

{"dataset":"random-100","experiment":"redis-docker-test","parallel":1,"top":1,
 "search_params":{"ef":128},"target_qps":null,"duration_seconds":null,"max_lateness_ms":null}

What lands in the artifact

engine_params, in *-search-*.json / *-upload-*.json (under params) and in *-summary.json (top level — so params is not the only place this PR writes, though results is untouched).

field	holds
declared	collection_params / upload_params as the configuration file spells them
effective	what the run used, after env + defaults + in-code pinning
env	which variables were consulted, and what was there (null = read and unset)
invocation	--host, --skip-upload, and every other measuring flag
overridden	declared value, used value, and why they differ
ignored_declared_keys	{exhaustive: false, covers: …, keys: [...]}
phase / schema_version	which phase this block describes; shape of the block (1)

Live evidence

Engines exercised live: redis and elasticsearch only. The other 13 rest on source reading, the guards, and unit tests. Everything below is one of those two.

Same config, four runs, only the environment and --host differ:

params WITHOUT engine_params (what master emits):   A==B==C==D ? True
params WITH engine_params:   A==B? False   A==C? False   A==D? False
  A (unset)                  effective=90000  env=None    host='localhost'
  B REDIS_QUERY_TIMEOUT=5000 effective=5000   env='5000'  host='localhost'
  C REDIS_QUERY_TIMEOUT=90s  effective=90000  env='90s'   host='localhost'
      overridden=[{declared:"90s", effective:90000,
                   reason:"environment value did not parse; the default was used instead"}]
  D (unset)                  effective=90000  env=None    host='127.0.0.1'

C is the case that matters most: the run used 90000, somebody tried to set something else, and the file says both. IGNORED_VAR=1, exported for run A and read by no engine, appears nowhere.

declared is the file text, not a serde round-trip — index_options.type and confidence_interval survive (the round-trip dropped both), casing is as written, no nulls injected.

overridden carries the ES pinned shard count (declared 3 / effective 1) and an entry from config::KNOWN_UNREAD, the repo's CI-asserted inventory, now wired in — the guard used to say "documented debt (#245)" while the artifact for that same config said nothing.

Server read-back (elasticsearch): recorded number_of_shards: 1 and ELASTIC_TIMEOUT: 300; live _settings {"refresh_interval":"-1","number_of_shards":"1","number_of_replicas":"0"}. Redis FT.INFO confirms the recorded env knobs and the derived index/prefix names. m and ef_construction are declared only and are not asserted against the server — that is #273, and "FT.INFO agrees with declared" is precisely the inference #273 exists to argue is unsafe.

Two credential leaks this PR introduced, found in review, fixed and re-verified

The invariant was checked over two flat maps while snapshot() emitted five value-bearing members. The three never inspected — invocation, declared, overridden — were exactly the three this block added.

	before	after
--host 'default:PW@127.0.0.1' (run succeeds, password authenticates)	"host": "default:PLAINTEXT-CANARY-hunter2@127.0.0.1" in 3/3 files	"host": "<redacted:set>@127.0.0.1", 0/3
config file api_key / auth_token / endpoint with inline userinfo	all three canaries in 3/3 files	0/3, vendor.cloud/v1 retained

Fixes, all at the choke point rather than per-caller:

• scrub_value walks the assembled document, so every member is covered and one added later is covered by construction. A value is secret if its key or any ancestor key is credential-named — which also closes record_effective("PASSWORD", json!({"value": s})).
• overridden entries name their knob in a sibling key field, so that field seeds secret-ness for the entry.
• strip_userinfo was wrong twice: it required scheme:// (but --host is a bare authority, and that is how the Redis-wire and Mongo engines take a password), and it computed the authority boundary before looking for @, so redis://admin:hunt/er2@10.0.0.5:6379/0 came back untouched.
• strip_dsn_secrets blanks password= inside opaque connection strings, where the secret sits under a key that is not itself credential-named.
• Markers widened — "AUTH_TOKEN".contains("_AUTH") is false, which is how auth_token slipped through. Now AUTH/TOKEN/PASS/ACCESS_KEY/PRIVATE_KEY/SIGNING_KEY/SESSION.
• <redacted:default> for an unset credential's built-in default, so the block no longer says env: null and effective: "<redacted:set>" about the same knob.
• Usernames stay in the clear — a deliberate, pinned decision (usernames_are_deliberately_recorded_in_the_clear): provenance, not a credential. Flip that test to flip the policy.

The wiring claim, withdrawn and re-earned

"Forgetting the reset is not expressible" was false. Four mutations reintroduced the bug with 776/776 green, and one — if engine_idx == 0 { begin_experiment(…) } — made the second config publish the first config's entire declared block and effective knobs. That is strictly worse than pre-#212: the artifact now affirmatively asserts a configuration that never ran, where master merely said nothing.

begin_experiment now returns a move-only Recording that run_single_experiment consumes. Verified:

mutation	before	now
// TODO(#212): re-enable begin_experiment(…)	survived	error[E0425]: cannot find value 'recording'
if engine_idx == 0 { … }	survived	error[E0425]: cannot find value 'recording'
hoist above the dataset loop	survived	error[E0382]: use of moved value: 'recording'
begin_experiment stops calling reset()	flaky (9 green / 11; 3/3 green under --test-threads=1)	killed deterministically

To be accurate about the last one: deleting reset(); from inside begin_experiment still compiles. It is killed by a test, not by inexpressibility — a pure Recorder-level test now, because the global-state version was masked by residual state from a previously-scheduled test (observe_env is first-write-wins). Only the three call-site mutations are inexpressible.

Root cause of the flake, now documented in the code: declared/invocation/phase are overwritten each experiment and self-heal, while env/effective/overridden/ignored only accumulate and are cleared by reset() alone.

Guards

1. No raw reads — scans src/**, strips #[cfg(test)], probes var/var_os/vars/vars_os/temp_dir/current_dir plus aliased imports. The src/config.rs exemption is now scoped to five named calls instead of the whole file. Proven with the drift probe.
2. KNOWN_UNRECORDED — 29 rows, 29 distinct literal env_var names, asserted both ways (stale row and missing row both fail with their own message). Also pins the count of non-literal env_var sites: there is exactly one (opensearch::parse_env_secs, a plain variable, no format!), and it is tier 1 because it calls record_effective.
3. the_experiment_loop_begins_a_recording_before_building_the_engine — strips comments first, and is now only a backstop for the ordering; the type does the rest.
4. every_measuring_flag_is_recorded_in_the_invocation — invocation was the one hand-maintained inventory here and had drifted by five flags including skip_vector_index. Now CI-asserted against every Args boolean, with verbose the only documented exclusion.

Not breaking existing consumers

• plot.rs production code byte-identical to master; over a 28-summary corpus (15 unversioned, 13 v2) master's chart and this branch's are diff -q identical.
• v0_check.sh reads six keys out of results, which this PR does not touch.
• metrics_schema_version stays 2 — it versions the metric definitions, which did not move. engine_params.schema_version is this block's marker.

Corrections to earlier revisions of this body

• Test counts: master (e99d2b5) 937, branch 1006, +69, 0 master tests removed. (An earlier revision said 934/+62 against fd92603; eight tests written for the block-list scanner went with it when the scanner was replaced. No test that exists on master was removed.)
• opensearch.rs is six hunks (new, build_base_url, upload_bulk_batch, RetryPolicy::from_env, parse_env_secs, SearchRetryPolicy::from_env) — the earlier "8 mechanical lines" and the correction's "five hunks" were both wrong.
• KNOWN_UNRECORDED is 29 rows, not 30.
• Tier-1 migrations: 13 knobs moved onto recording helpers, plus 7 backstopped with an explicit record_effective — not "14".
• Binary md5 dropped (a debug binary embeds its build path, so the hash is unverifiable). Branch a3c6146, rustc 1.97.1.
• The schema-version test is snapshot_carries_schema_version_one.
• The NBSP trim case is now actually tested, not just documented.
• The ES evidence uses an author-written config: nothing shipped declares number_of_shards for elasticsearch.
• The RED baseline ran a hand-adapted variant; the shipped test cannot compile on master.

Known, tracked, and NOT fixed here

effective.number_of_shards still asserts a value the server does not have. With --skip-upload, an OpenSearch config declaring 1 publishes effective.number_of_shards: 1 against a server holding 3, overridden: []. The value is pre-existing (#211) but this PR promoted it into a block whose contract forbids exactly that. It is the one surviving instance of the bug that motivated the split — written up on #273, which fixes it with the same read-back.

Third review pass — three more blockers, fixed

1. strip_dsn_secrets leaked. The function added to close the libpq case split on whitespace before parsing, so a legal quoted value published everything after the first space:

config:    password='LEAKONE LEAKTWO LEAKTHREE'
artifact:  password=<redacted:set> LEAKTWO LEAKTHREE'

Replaced with a quote-aware scanner honouring single/double quotes and backslash escapes. The shapes that already worked (bare, leading, tab-separated, double-space, uppercase PASSWORD=, api_key=, auth_token=) still do, and options='-c statement_timeout=5s' is untouched.

2. An overridden entry on a credential knob recorded nothing. Seeding secret-ness from the sibling key field blanked that field and reason too, so the entry rendered as four identical placeholders — destroying exactly what it exists to produce. Same shape cost a {"key":…, "value":…} header list its names. Fixed in the scrubber and the assertion together: the assertion required the blank and panicked on a correctly-scrubbed document.

3. The reset guard was not a guard. begin_clears_every_accumulating_field exercises Recorder::begin, which the mutation does not touch. The only test that ever failed relied on residue other tests left in the global recorder — 9 green / 2 red at default threads, 3/3 green under --test-threads=1, 3/3 red only in isolation. Replaced with a test that drives begin_experiment itself and seeds every accumulating field explicitly: with reset() deleted it now fails 7/7 — alone, in-suite, and single-threaded.

And this branch had introduced a guard blind spot. A #[cfg(test)] const has no brace, so strip_test_modules brace-counted from the next { — the following function's body — deleting ~25 lines from the scan; a raw std::env::var planted in parse_update_search_ratio was missed with 786/786 green. strip_test_modules is now indentation-based, which also fixes the pre-existing failure on the five files whose string literals contain braces, and strips comments first. Verified: the planted probe is caught.

Claims corrected rather than defended

• Recording proves a recording BEGAN, not that it began for this pair. A token minted for a different experiment compiles and passes. The compile errors are real (E0425 ×2, E0382); the identity claim was not.
• EXEMPT_CALLS was documented as asserted-present and was only a skip-list. It now has the assertion its docstring promised — which then caught two real problems of its own: a stale row, and a strip_test_modules bug that was blanking 2300 lines of config.rs.
• invocation is bidirectional over bool fields only. --repetitions and --warmup-seconds change what is measured, are now recorded by hand, and the guard's limit is stated in its own docstring. Widening past booleans is results JSON is content-attributable but not reproducible: no tool SHA, config file identity, dataset checksum or connection_params #274.
• Redaction changes a JSON type — a number under a credential-named key becomes a string. Zero false positives across all 31 shipped configs and all 104 recorded knob names today, so drift risk rather than live defect; noted at the line that does it and filed as effective_config guard blind spots, is_secret over-matching, and the JSON type change from redaction #289 with the two guard blind spots (use std::env::{var}, env_var(&…)).

The invocation guard earned itself on the first merge

Merging origin/master (#271) immediately failed it:

these Args flags change what a run does but reach no artifact: ["allow_partial_corpus"]

--allow-partial-corpus suppresses the short-corpus refusal, so it permits a wrong recall under a config name that claims otherwise — precisely the flag an artifact most needs to state. Now recorded.

origin/master is merged, not rebased (published branch, no force-push). #271 adds a corpus_reuse argument to build_search_result_json; kept alongside engine_params.

Fourth review pass — a second form of the same leak, fixed

BLOCKER: a password in a URL query string was published verbatim, on the same --host flag the "two leaks fixed" table above is about. That table's demo (default:PW@127.0.0.1) is the userinfo form and was genuinely fixed; this is a different form:

mongodb://h.example/db?w=majority&password=CANARY   -> unchanged
redis://h:6379/0?db=1&password=CANARY               -> unchanged

strip_userinfo declines (no @), and the whitespace-splitting DSN scanner read the key as mongodb://h.example/db?w — not credential-named — so the tail came through into invocation.host in all three file kinds.

Worth understanding before trusting the fix: ?authSource=admin&password=X was redacted, but only by accident — the first key contains AUTH, which blanked the whole tail. Any benign leading option restored the leak. The regression test therefore pins the benign-leading-option cases explicitly, so accidental masking cannot make a future regression look green.

Rewritten as a real key=value scanner — separators whitespace/&/;/?, spaces allowed around = (PostgreSQL documents them as optional), quoted values honouring backslash and SQL doubled-quote escapes. That also closes the eight other shapes the 44-case corpus found: spaces-around-eq, space-before-eq, space-after-eq, sql-doubled-quote, pwd= (a plain marker gap — password/passwd/PGPASSWORD matched, pwd did not), jdbc:, &-separated, and both ODBC ; forms. Non-secret pairs are reproduced byte for byte, options='-c statement_timeout=5s' included.

Verification note: this shape cannot be driven end-to-end through the binary — every client rejects ?password= as an unknown option before any file is written, which is exactly why the redactor must not depend on that. It is asserted on the serialized result document, which is byte-identical to what save_search_results writes, plus through Recorder::snapshot() directly. The userinfo form is still verified end-to-end on disk.

Two more scanner over-strips, each proven with a planted probe

• A bodiless #[cfg(test)] mod filter_guard; (engine/mod.rs:12) has no block, so the scan hunted for the next column-0 } and deleted lines 13–60 — the #[cfg(test)] const bug in a different item shape, and it contradicted the comment I had shipped saying non-module items are never deleted.
• A trailing comment on a closer (} // end of the config tests) left "} " after comment-stripping, never matched, and ran to EOF — silently disabling guard 1 for the rest of the file.

Both fixed and both probes now caught. Added a fail-safe: an unterminated module emits its lines rather than deleting to EOF, since over-scanning is a visible false positive and under-scanning is invisible.

Three false claims, two of them shipped in the repo

• --repetitions / --warmup-seconds were not recorded. An earlier edit aborted before writing and the claim survived in the PR body, a commit message, and a code comment that the guard's boolean-only limit leans on. Now actually recorded.
• invocation.configurations_dir did not exist — it was cited as the compensating control waiving guard 1 for env::current_dir(). Now emitted (with results_dir), and a new test asserts the cited record exists; the old assertion only checked the excused call was still there.
• begin_experiment's docstring still claimed inexpressibility. Corrected in the code, where it had been contradicting Recording's own docstring in the same file.

Also: the invocation guard now bites both ways (a fabricated key mapping to no Args field was green), and EXEMPT_CALLS matches stripped production text — which immediately caught a stale row of its own, src/config.rs: env::var(k), excusing a read that lives in a #[cfg(test)] helper. Deleted.

On the trailer: settled — this repo squash-merges and the squash message is authored explicitly, so e5f4f02's superseded Closes #212 never lands.

Fifth review pass — the design change

Seven more credential shapes reached results/*.json: percent-encoded (%70assword=), Cyrillic homoglyph (pаssword=), AccountKey=, bearer=, Pwd= inside quotes, and any pair nested in a quoted run under a non-secret key. Every one is the same class — tokeniser desync. A single unbalanced quote disabled the redactor for the rest of the string.

Three rounds each closed the demonstrated case and left the class open, so the fix is a design change rather than an eighth patch: the default is inverted.

redact_connection_like REBUILDS a connection-like value from positively recognised components — scheme, host, port, path, and allow-listed parameters whose values are simple — and drops everything else, echoing only the sanitised parameter name:

mongodb://h/db?w=majority&password=X  ->  mongodb://h/db?w=majority&password=<dropped>
redis://admin:pw@10.0.0.5:6379/0      ->  redis://<redacted:userinfo>@10.0.0.5:6379/0
pаssword=X  (homoglyph)               ->  <dropped>
cs="Server=h;Pwd=X;"                  ->  cs=<dropped>

Nothing reaches the artifact unless it was recognised, so a desync loses benign detail instead of publishing a credential. None of the seven shapes had to be predicted — their parameter names simply are not on the allow-list. options is deliberately excluded because its value can itself contain pairs (options='-c password=X' is a live libpq shape).

A string containing none of ://, @, = is returned unchanged, which is the overwhelming majority of what gets recorded (localhost, idx:redis-docker-test, FLOAT32, filesystem paths).

Live, all nine reported shapes, isolated Redis, artifacts on disk:

label                      rc  files leaked  recorded invocation.host
query-string-password       0    3     0     mongodb://h/db?w=majority&password=<dropped>
percent-encoded-key         0    3     0     mongodb://h/db?<dropped>
quoted-nested               0    3     0     options=<dropped>&password=<dropped>
unbalanced-quote            0    3     0     x=<dropped>&password=<dropped>
odbc-in-quotes              0    3     0     cs=<dropped>&Pwd=<dropped>&<dropped>
azure-accountkey            0    3     0     DefaultEndpointsProtocol=<dropped>&AccountKey=<dropped>
bearer                      0    3     0     bearer=<dropped>
userinfo-baseline           0    3     0     <redacted:userinfo>@127.0.0.1
homoglyph                   0    3     0     <dropped>

REDIS_URI=redis://127.0.0.1:6411/?password=X -> rc=0, 3 files, 0 leaked,
  env.REDIS_URI = "redis://127.0.0.1:6411/?password=<dropped>"

The false claim that caused this

My shipped comment said "every client rejects ?password= as an unknown option before a file is written". It is false — redis-rs ignores the unknown param and the run completes with rc=0 and three files. I used it to justify asserting on the in-memory document instead of on disk, and that is exactly what let seven shapes survive a round. The comment is deleted and the corpus test now writes real files and greps the bytes, across search, upload and summary artifacts.

strip_test_modules: pinned at last

Three more over-strips (a // inside a string literal — 93 lines under src/ — a block-commented fake module, and a block comment after a bodiless mod X;). Six such bugs had been found by hand across four passes and none was pinned. It now has a table-driven test, which immediately exposed a seventh: a /// doc comment mentioning experiments/configurations/*.json contains /*, so stripping block comments first ran to EOF and blanked 2300 lines of config.rs — project_root's env::current_dir() among them. Caught by the exemption assertion added the previous round.

Also fixed

• repetitions / warmup_seconds were recorded but unguarded — deleting either left the suite green while NON_BOOL_INVOCATION_KEYS made them look covered. Now asserted present.
• NON_LITERAL_ENV_VAR_SITES deduped file paths, so a second dynamic env_var(x) in one file passed. No longer deduped; the named function must exist too.
• Five false shipped comments corrected: the stale format!/base-var claim that survived 25 lines from its own correction; two different figures for one 11-run measurement; the src/config.rs whole-file exemption prose left behind after the list changed; start_gate.rs named as containing { literals when it has none; and "104 recorded knob names" where the derived figure is 97.
• PR-body corrections: the DSN list enumerated nine shapes while calling them "eight"; EXEMPT_CALLS is four scoped rows, not five (the previous commit deleted the fifth); and queries, timeout, search_timeout, upload_start_idx, upload_end_idx, parallels, ef_runtime, update_search_ratio reach no invocation key — the boolean-only limit is stated correctly further down and the summary contradicted it.

Merged origin/master (#278 cff7e3a, then #286 7ed81eb)

Merged, not rebased. Verified rather than trusted, since a clean git merge is not evidence — when #271 merged into #236 the merge was clean and the run published Recall: 0.0000 at exit 0:

• Recorder ordering survived: begin_experiment (experiment.rs:366) still precedes create_engine (:372), so --host is still recorded before any client can reject it — the property the redaction has to hold under.
• index_naming.rs composed correctly: fix(vectorsets): derive the vector-set key per config so concurrent runs stop clobbering each other #278's docs and two tests came in, my recorder wiring (env_or / env_flag) stayed. No raw std::env::var reintroduced in any of the three engine files fix(vectorsets): derive the vector-set key per config so concurrent runs stop clobbering each other #278 touched.
• corpus_row_count names self.config.key, not the hardcoded idx of the fix(skip-flags): --skip-upload must reuse the corpus, not destroy it (#238) #271×VectorSets uses a hardcoded idx key — it never got the #151-4 per-config namespacing, so concurrent runs clobber each other #236 hazard; fix(vectorsets): derive the vector-set key per config so concurrent runs stop clobbering each other #278's new MERGE HAZARD comment carries no /* that would trip the comment-stripping fix from the previous commit.
• The scanner still sees the rewritten vectorsets.rs: planted probes at four depths (24, 300, 537, 900) are all caught.
• Live on the merged tree: redis recall 1.000, 0/3 canary leaks, invocation.host = <redacted:userinfo>@127.0.0.1. A two-config vectorsets sweep isolates idx:vs-a / idx:vs-b, both recall 1.000, and their artifacts correctly attribute M=16 vs M=32 — results JSON does not record collection_params or env-derived engine knobs, so tuned runs are indistinguishable #212's capability working on the engine fix(vectorsets): derive the vector-set key per config so concurrent runs stop clobbering each other #278 rewrote.

One real defect the merge introduced, fixed

#278's two new index_naming tests resolve through the process-wide recorder without holding test_lock, so an observation could land between another test's begin_experiment and its snapshot(). Six consecutive green suites did not disprove it — the window is a few instructions — and "measured green" is exactly the evidence that was wrong about this test before. Closed two ways: those tests now take the lock, and the sweep-bleed assertions now name the keys they seeded instead of asserting total emptiness. Equally strong against the mutation (deleting reset() still caught 5/5: 3/3 alone, in-suite, and --test-threads=1), and immune to a concurrent writer.

#286 (7ed81eb) — geo-radius filters

#286 added engine/geo.rs and rewrote comment blocks across eight engine files, all of which are new input to the source-scanning guards.

• No new environment reads, so neither KNOWN_UNRECORDED nor EXEMPT_CALLS needed a row — and since both assert bidirectionally, a missing one would have failed loudly rather than silently.
• geo.rs carries none of the shapes that broke the scanner before: no /* inside a /// doc comment, and its // no radius-style trailing comments sit outside string literals, which the literal-aware stripper handles.
• Scan boundary pinned by probe, not assumed: planted std::env::var at geo.rs:100 and :281 → both CAUGHT; at :400, inside the #[cfg(test)] mod tests that starts at 282 → correctly not scanned. Probes in the rewritten mongodb_engine.rs and milvus.rs → CAUGHT. All six guards pass.
• Recorder wiring survived in every file Geo filters: implement for VectorSets, Milvus and MongoDB; pin Chroma/Turbopuffer as real gaps (#223) #286 touched (valkey 13 sites, mongodb 8, milvus 4, turbopuffer 2), and begin_experiment still precedes create_engine.
• Live on the merged tree: redis recall 1.000, 0/3 canary leaks, invocation.host = <redacted:userinfo>@127.0.0.1; two-config vectorsets sweep isolates idx:vs-a/idx:vs-b, both recall 1.000, artifacts attributing M=16 vs M=32.

The one inventory that was not bidirectional

UNCOMPILED — the list of directories the source scanners skip because nothing compiles them — had a skip filter and no assertion, while KNOWN_UNRECORDED and EXEMPT_CALLS are both asserted both ways. A stale row there is the worse kind: it silently widens what the scanner ignores. With src/vectorsets/ (#297) and src/redisearch/ (#296) both queued for deletion, it would have rotted unnoticed.

Now asserted, both legs proven to bite:

• exists — moving src/vectorsets/ away (simulating chore: delete src/vectorsets/, a PyO3 module that has not compiled since Feb 2026 #297) fails with an actionable message naming the row to delete;
• not declared by any crate root — adding a row for src/readers/, which lib.rs does declare, fails with "IS declared as a module and therefore compiled". This is the leg that matters: adding mod vectorsets; would otherwise bring 1,400 unscanned lines into the build.

Leg 2 could not be shown using vectorsets itself, because adding pub mod vectorsets; to lib.rs does not compile — independent support for #297's premise that the directory is dead, separate from its docker build evidence.

The four src/config.rs exemption reasons justified themselves by naming those two directories as RedisConfig::from_env's only callers — half-true after #297, false after #296. They now assert the durable property instead (the_exempted_dead_constructor_has_no_live_caller; planting a real call in engine/redis.rs fails it), and say that after both deletions the right move is deleting the constructor rather than exempting it.

For whoever merges #297 or #296 second: the fix is deleting one string from UNCOMPILED. Flagged on #297.

Sixth review pass — a regression against this branch's own round-2 fix

B1. redact_connection_like sliced the authority on /?# before looking for @, so a password containing any of those pushed the @ out of the slice and admin:LEAKCANARY fell through to the host slot. b9d4e02 had an explicit "malformed-but-dangerous fallback" for exactly this — added in round 2, cited in this body — and the round-5 rewrite dropped it and reproduced the bug verbatim. Six shapes, 3/3 files each, plus REDIS_KEY_PREFIX through the same choke point.

Fixed by locating @ over the whole remainder before any slicing, and allow-listing the host slot: scrub_authority emits only host or host:port with a numeric port, so a stray : makes the token unrecognised rather than printable.

B2. value[..i+3] was emitted as "the scheme" — actually all text before the first ://, so password=LEAKCANARY;endpoint=x://h was republished byte for byte. Schemes are now allow-listed; an unknown-but-well-formed scheme becomes <dropped>://, and a prefix that is not a scheme makes the whole string parse as a parameter blob so the allow-list runs.

B3. The inversion had been applied to connection-string values but not to JSON keys. bearer and AccountKey were described in this body as "closed by construction" — true as parameter names, wide open as key names. Declared keys are now allow-listed too (DECLARED_KEY_ALLOWLIST, derived from all 47 keys the shipped configs use); numbers and booleans pass regardless of key.

Live, real binary, exit 0 — all previously-leaking inputs now 0/3:

redis://admin:LEAKCANARY/x@10.0.0.5:6379/0  -> redis://<redacted:userinfo>@10.0.0.5:6379/0
default:LEAKCANARY/x@127.0.0.1              -> <redacted:userinfo>@127.0.0.1
postgresql://bench:LEAKCANARY#1@db:5432/vec -> postgresql://<redacted:userinfo>@db.internal:5432/vec
password=LEAKCANARY;endpoint=x://h          -> password=<dropped>&endpoint=<dropped>
LEAKCANARY://h                              -> <dropped>://h
12 JSON-key canaries (bearer/jwt/pw/odbc/…) -> 0/12 on disk, M and EF_CONSTRUCTION intact

The structural fix, which matters more than the three

• CONNECTION_SHAPE_CORPUS is append-only, 44 entries, floor asserted. Five rewrites each closed what was just reported and lost something closed earlier, because the corpus only ever grew by the latest finding.
• Canaries on both sides of every delimiter, asserted mechanically for @. Round 5's userinfo-slash-pw had its canary only after the /, in the half that gets dropped — the two rows naming the shape were the two hiding it.

Also

SAFE_PARAM_KEYS and is_secret contradicted each other in one artifact (?authSource=admin published, "authSource": "admin" redacted). authsource/target_session_attrs are dropped rather than exempted, so no_allow_listed_parameter_is_credential_named can be enforced — which is what blocks sslpassword, passfile, proxyPassword and authMechanismProperties from being added in good faith later.

Over-redaction stays clean: 0 of 212 shipped config entries lose a value. configurations_dir/results_dir are now ~-relative instead of publishing /home/<username>/….

Seventh pass — the generative campaign, and the end of the hand-rolled parser

A generative campaign (823,920 cases, 116,434 leaking, 5 root causes) found in one pass what six hand-picked rounds did not. Every finding was a desync state of my tokeniser, not a missing rule, so the tokeniser is gone:

• scheme:// values are parsed by the url crate and rebuilt from the structured fields it returns. Userinfo is never one of them, so a @ inside a query value cannot promote that value's tail into the host slot (L1 — the worst, because the leaked bytes sat immediately beside <redacted:userinfo>, asserting redaction at the exact point it failed). redis://[admin:LEAK] now fails to parse and is digested rather than passing a bracket check that never looked inside the brackets (L3).
• Anything that is not a parseable URL becomes <redacted:opaque sha256=… len=…> — identity without disclosure. L2 (Server:h;Pwd:X — no ://, @ or = at all) and L4 (a quoted fragment resembling an allow-listed key) existed only because the code tried to salvage readable output from arbitrary DSNs.
• Scheme-less authorities (--host default:pw@node, the commonest form) are parsed with a synthetic scheme so url decides where userinfo ends. Two ambiguity gates — an @ delimiting no userinfo, and userinfo followed by an implausible host — both digest, so --host p@ssword no longer publishes ssword.

Live, real binary, exit 0:

@LEAKCANARY                                    0/3  <redacted:opaque sha256=d44c3384 len=11>
p@ssLEAKCANARY                                 0/3  <redacted:opaque sha256=3a76d003 len=14>
default:LEAKCANARY@127.0.0.1                   0/3  <redacted:userinfo>@127.0.0.1
user:LEAKCANARY@redis.internal:6379            0/3  <redacted:userinfo>@redis.internal:6379
REDIS_URI=…?password=p@ssLEAKCANARY1           0/3  redis://127.0.0.1:6473/?password=<dropped>
host=db user=bench password=p@LEAKCANARY       0/3  <redacted:opaque sha256=895898a0 len=40>
password='a db=LEAKCANARY c'                   0/3  <redacted:opaque sha256=27c07319 len=28>
mongodb://h1:27017,h2:27017/db?replicaSet=rs0  0/3  mongodb://h1:27017,h2:27017/db?replicaSet=rs0
localhost                                      0/3  localhost

The permanent generator

Fixed seed, 4000 bounded cases, in CI. Ground truth by construction: the generator knows which spans it placed in permitted slots (host, port, path, allow-listed values) and which in forbidden ones (userinfo, non-allow-listed parameter values). Forbidden spans carry a canary; the oracle is that no canary survives — through redact_connection_like and through the full snapshot path. Asserted non-vacuous (>2000 cases must actually contain a forbidden span) and mutation-checked: publishing query values verbatim fails it in 2 cases.

The reviewer's framing is the right one and is now reflected in the code: the append-only corpus makes a lost fix fail; only a generator makes an unanticipated shape fail. They are orthogonal — the both-sides-of-a-delimiter rule was satisfied by every corpus row and was simply the wrong dimension for L1.

Over-redaction fixed, not accepted

Replica-set seed lists (mongodb://h1:27017,h2:27017/db) and SQL Server host,port survive, via an explicit host-list check applied only when every element parses as host[:digits]. The previous version dropped the whole host list.

One new direct dependency: sha2 = "0.11", matching the version already in the lock. (url was added and then removed again — nothing parses now.)

Eighth pass — the parser is deleted

The re-run found six more classes in 381k cases, and BLOCKER 1 was the host-list feature added the previous round to recover provenance: split_authority searched for @ across the whole remainder, so a @ in a query value made the text after it the "authority" — printed verbatim beside a <dropped> claiming redaction, and replacing the real host.

That is the pattern rather than an accident. Eight rounds, seven leaked; every mechanism that preserved readable output was a parser and every parser had a desync. So redact_connection_like is now two outcomes and no third path:

• a plain token ([A-Za-z0-9._+\-/~] only) is the identity;
• everything else is <redacted:opaque sha256=…>.

No URL parse, no authority split, no host display, no query-pair echo, no scheme or parameter allow-list. ~200 lines deleted. B1–B3, SF4 and SF5 are unreachable by construction: there is no slice of the input on any path to the artifact.

: is deliberately not in the plain alphabet — no shape test distinguishes admin:Sup3rSecret from idx:redis-docker-test, so index names digest too. They are derivable from params.experiment; a published password is not derivable from anything.

Live, real binary, exit 0 — every reported shape 0/3:

redis://127.0.0.1:6379/?password=p@Secret,LEAKCANARY  -> <redacted:opaque sha256=bb17991e546024bd>
mongodb://cluster.example.net/db?password=a@b,LEAK…   -> <redacted:opaque sha256=305684b752b14d55>
redis://h#@LEAKCANARY,Z                               -> <redacted:opaque sha256=88dac1570b6299dd>
redis://default:p@sswordLEAKCANARY                    -> <redacted:opaque sha256=7da83c6d4f062336>
default:MyP@ssR8LEAKCANARY.w0rd                       -> <redacted:opaque sha256=d66971fc17da0fdd>
?password=abc&Sup3rLEAKCANARY                         -> <redacted:opaque sha256=6fc1cfb0d0586aa7>
Server:h,Pwd:LEAKCANARY / Server:h Pwd:LEAKCANARY     -> digest
admin:Sup3rLEAKCANARY                                 -> digest
localhost                                             -> localhost

The generator was the reason these survived

• Its oracle was whole-canary containment while every live class leaked a fragment — round 6's own p@ssX -> ssX would have passed it. Now a 5-char contiguous-run check, mutation-checked twice (republishing the tail after @, and leaking a bare 6-char suffix — both caught).
• Delimiters are now placed inside the secret, not only after it.
• Commas exist at all — the dimension round 8's blocker came from.
• Secrets use a G–Z alphabet, disjoint from lowercase hex, after the first run produced a false positive against the digest's own characters.

Corpus +11 (floor 44 → 55)

Bracketed authority (L3 — demonstrated in round 7 and never appended, despite the append-only rule), the comma/host-list shapes, Server:h,Pwd:X, Server:h Pwd:X, bare admin:secret, and ?k=v&secret with no =.

The both-sides rule is now a weak per-row check plus a corpus-wide set property. An @ cannot be classified soundly per row — a / inside the password moves the apparent authority boundary — but the corpus must contain rows probing both halves, which is the dimension it actually lacked.

Smaller items

sha2 = "0.11" matching the lock ("0.10" had pulled in six crate versions including generic-array, absent from the lock entirely). 8 digest bytes, not 4 — 4 collided 5 times in 200k values. len= dropped: it disclosed the credential's exact character count.

The cost, stated plainly

Readable endpoints are gone from artifacts. REDIS_URI, --host, index_name, key_prefix and every DSN now render as a digest. The digest still answers "did these two runs use the same endpoint?", which is the question #212 is about; the endpoint itself is in the operator's shell history. Recovering structured-but-safe output later is possible, but only behind a parser, and the record here is seven leaks in eight attempts.

Ninth pass — the design held; two paths it did not cover

The adversarial campaign on digest-everything came back clean: 961,344 cases through twelve injection points, zero leaks, all six prior classes unreachable or fixed, 1,000,000 distinct DSNs with 0 digest collisions, and over-redaction measured at 1 of 246 shipped-config string values. Two real findings remained.

A third identity path published operator input verbatim. prose was derived by matching the JSON key name against ["reason","covers"] at any depth — and set_declared forwards a raw, un-allow-listed config subtree into note_override. A config placing a {"reason": …} object at one of three CI-pinned paths therefore published it in the clear: the same value <dropped> on the allow-listed path and cleartext two keys away, which is precisely the class this whole series exists to kill.

PROSE_KEYS is deleted. reason is now &'static str on an Override struct, held outside the scrubbed tree and spliced in by position after the scrub; covers is a hoisted literal handled the same way. Only a string literal can reach either — a property of the type, which a key name cannot forge.

The leak guard printed the credential it caught, under no cfg, so in release too. It fires only when the redactor has a bug — the exact moment the value must not be written anywhere — and benchmark stderr gets pasted into issues. The value is now digested in the message.

Generator and corpus

• The canary_before_at >= 5 floor had slack 9 against an actual 14, so nine @-rows could be silently defanged — including userinfo-slash-pw, the row that memorialises round 5's regression, whose defanging survived 850/850. Now asserted per row for every userinfo* label; the exact mutation is verified to fail.
• The plain-token alphabet is pinned. Adding @, ;, &, #, ?, %, ,, * or ! each survived the whole suite; only : and = were covered by anything.
• assert!(checked > 5000) was tautological — it counted loop iterations. It now counts cases that actually reached the digest path.
• The doc states where the generator's coverage stops: it drives redact_connection_like and invocation.host only, so no seed of it could have produced the prose finding.

Documented rather than changed

is_plain_token protects nothing punctuation-free — a bare hunter2, a UUID, ghp_…, AKIA… are all published, and is_secret on the key is the sole defence for those. And the digest is an unsalted hash, so it is a commitment: a guessed endpoint can be confirmed offline. Both are the intended trade for "same connection ⇒ same token across runs"; neither had been written down.

Merged caefe0f (#297)

UNCOMPILED lost its src/vectorsets/ row — the bidirectional assertion added when #297 was opened failed on the merge and named the exact string to delete. Planted-probe checks re-run across the merged tree (59 files): experiment.rs, engine/mod.rs, engine/vectorsets.rs, engine/geo.rs, src/config.rs, src/start_gate.rs all CAUGHT.

Tenth pass — the sentinels were fiction

<dropped> and <redacted:default> never reached an artifact. snapshot scrubs the whole assembled document, so both were re-processed: <dropped> is not a plain token and digested to the hash of the literal <dropped>, and <redacted:default> under a credential-named key fell through to <redacted:set>.

The second is the prose bug inverted. A run with no password set published

"effective": { "ELASTIC_PASSWORD": "<redacted:set>" }

— the artifact asserting a credential was supplied when the built-in default was used. record_effective_raw existed to prevent exactly that and was defeated, so env_or's set-vs-default branch was dead as far as the artifact was concerned. Eight comments and a commit message asserted the behaviour; nothing asserted it in a test, which is why it drifted.

scrub_value now passes an already-emitted sentinel through unchanged. Live, real binary:

ELASTIC_PASSWORD (no password set) : "<redacted:default>"
declared.bearer  (unknown key)     : "<dropped>"
declared m / ef                    : 24 / 200
canary on disk                     : False

Both pinned by tests; removing the arm fails them.

The splice's positional coupling between assemble and snapshot was a convention shared by two functions and asserted nowhere — reversing the iteration mis-attributes every reason and left all 852 tests green, because no test had two overrides with distinct reasons. Now three, checked pairwise; the .rev() mutation fails it.

NITs

• Round 5's exact shape was still defangable on the row that memorialises it. "Some canary before the @" passed for redis://admin:pw/CANARY@10.0.0.5:6379/0 — the canary sitting in the half the buggy code dropped. The rule is now "in the userinfo, before its first internal delimiter"; that mutation dies.
• The docstring claimed "a canary on BOTH sides" while the code three lines down required some side. It now describes what is asserted.
• MINIMUM_SHAPES was 55 against an actual 56 — one row deletable silently.
• mongodb-srv had userinfo but its label skipped the per-row loop; renamed with a two-part canary.
• The chore: delete src/vectorsets/, a PyO3 module that has not compiled since Feb 2026 #297 remediation was half-followed — the row went, the prose did not. Three passages still described src/vectorsets/ as live or its deletion as pending.

Eleventh pass — the sentinel pass-through was a bypass

is_sentinel matched three placeholders exactly and the digest by prefix, and its arm sat above both the credential-key guard and the redactor. Confirmed on disk before fixing:

--host '<redacted:opaque sha256=x> password=FORGEDCANARY'
  -> "host": "<redacted:opaque sha256=x> password=FORGEDCANARY"   3/3 files

This is the guards-one-notch-weak pattern inside the fix for the previous instance of it — three sentinels compared exactly, the fourth by prefix because its content varies, and nobody varied the suffix.

Fixed structurally rather than by tightening the predicate, because a String that merely looks like this module's output is the ambiguity that has cost this PR ten rounds. There is no longer anything that asks the question:

• the write path stores raw values — observe_env, record_effective, note_override, set_declared no longer scrub;
• snapshot scrubs once, per member, over values this module has never processed before, with the key in hand;
• the declared-key allow-list is folded into that same traversal, so <dropped> comes from a terminal arm rather than an earlier pass whose output the scrub re-read;
• <redacted:default> is a marker on the key (from_default: BTreeSet), not a magic string in the value.

is_sentinel, record_effective_raw, redact and allowlist_declared are all deleted.

A credential-named declared key now reads <redacted:set> rather than <dropped> — "we removed a secret" and "this knob is not one we read" are different facts, and the leak guard was right to reject the second standing in for the first.

Corpus +6 forged-sentinel rows (floor 56 → 62), each a sentinel prefix followed by a canary, because the suffix is the dimension an exact-match test passes and a prefix-match test leaks. Verified: reintroducing the prefix bypass fails no_connection_string_shape_publishes_its_credential on forged-digest-prefix.

Live: reproducer 0/3; a run with no password set still publishes <redacted:default>, an unknown declared key reads <dropped>, m/ef_construction read normally.

Twelfth pass — the doc outlived the property

Correction to 3b27709's commit message, which named the wrong guard for its own verification. It claimed reintroducing the prefix bypass fails no_connection_string_shape_publishes_its_credential; it does not — that test calls redact_connection_like directly while the bypass arm sat above it in scrub, so the mutation passed 855/855. The only guard that fails is experiment::…::no_shape_reaches_the_files_on_disk on [forged-digest-prefix]. That matters beyond bookkeeping: a future reader deleting the "redundant" on-disk test would remove the sole coverage.

SF1. snapshot's doc still claimed the assembled-document scrub made "cannot miss a map somebody adds later" true rather than aspirational. Removing the double pass put the manual enumeration back and the claim went stale with it — three members already sat outside it (phase, overridden[].key, ignored[]). No disclosure, since all three carry names, but the doc asserted a guarantee the code no longer provided, which is the exact failure this module exists to prevent.

Fixed on both sides rather than just the doc: phase is &'static str; the two name members go through the same value scrub; and member_set_is_pinned_so_a_new_one_must_be_scrubbed_deliberately replaces the guarantee the restructure removed — adding a member is now a build failure that names the fix. Verified with an unscrubbed member.

A hole surfaced while proving those three were safe: JSON map keys are never scrubbed anywhere. Correct in general — they are structure, not data — except under declared, whose keys come from the configuration file, where {"password=SECRET": 1} publishes the secret in a position no value scrub can see. A non-plain-token declared key is now digested; all 47 shipped keys are plain tokens so it costs nothing.

SF3. record_effective's doc still opened "Redaction happens HERE, not in the callers" in a function whose body is a bare insert — contradicted by the same commit that wrote it.

NITs. BEARER added to SECRET_MARKERS (the corpus carried bearer= as a credential shape while the marker list did not, so index_params.bearer read <dropped> rather than <redacted:set> — harmless while dropped, a live leak the moment anyone allow-lists the key). begin()'s "four of the seven fields" is now five of eight with from_default asserted. Dead let _ = is_secret(key); removed.

Merged e99d2b5 (#298) — a clean merge that did not compile

git reported no conflict, and the tree did not build: #298 added two tests calling build_search_result_json with master's 11 arguments while this branch's twelfth is engine_params. The two sides touched different lines of the same call. Second time this cycle in exactly that shape, and the reason "a clean merge is not evidence" is worth repeating.

Checked rather than assumed: the recorder wiring survived (begin_experiment :366 still precedes create_engine :372; #298's gate_update_attribution lands at :1043 with its call site at :1585); no raw environment read was reintroduced anywhere under src/; planted probes CAUGHT in all six files #298 touched.

The three new artifact fields do not touch the scrub path, verified: update_failures / update_unattributed are counters, update_attribution is a closed three-value enum via as_str() -> &'static str, and update_attribution_detail is a per-engine literal at all five call sites. They land in results, not params.

That prompted the one substantive change: the member-set guard now states its scope. It pins engine_params and nothing else, and extending it artifact-wide is not viable — server_metadata alone contributes ~1,400 server-supplied strings from a full INFO/CONFIG dump. Checked while establishing that: server_metadata carries its own redaction, emitting a distinct <redacted> for requirepass, masterauth and tls-*-pass, so that surface is covered by its own mechanism rather than uncovered. Documented, so nobody reads the guard as spanning the file.

Deliberately left out (all filed)

• record the resolved index params by reading them back off the server (split from #212) #273 — resolved index params via server read-back, per-engine coverage marker, vectorsets first (it drops lowercase m silently and is the only engine file untouched here). Carries Closes #212.
• results JSON is content-attributable but not reproducible: no tool SHA, config file identity, dataset checksum or connection_params #274 — tool git SHA, config file identity, dataset checksum, connection_params, summary timestamp, README artifact contract.
• effective_config guard blind spots, is_secret over-matching, and the JSON type change from redaction #289 — guard blind spots, is_secret over-matching, the JSON type change.
• dead code: uncompiled src/redisearch + src/vectorsets, recorder-bypassing RedisConfig::from_env, and WEAVIATE_USE_GRAPHQL=false selects GraphQL #275 — dead src/redisearch/ + src/vectorsets/ and RedisConfig::from_env; WEAVIATE_USE_GRAPHQL semantics.
• Instrumenting SearchParams::knob() — engines also reach typed fields directly, so it would report false ignores.

Gates

cargo fmt --check clean · cargo clippy --all-targets -- -D warnings clean · cargo test --lib --bins 1006 passed, 0 failed: lib 129, vector_db_benchmark 875, generate_dataset 2, bench_hdf5/bench_jsonl/bench_npy 0 each. Against master 7ed81eb (905, measured in an isolated worktree). All 22 test binaries compile.

Refs #212

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)

[github-actions]

Docker Build Validation

Platforms tested:

• linux/amd64 (built and tested)
• linux/arm64 (build validated)

Tests performed:

• --help command
• --describe datasets command
• Integration test (random-100 dataset + Redis)
• Multi-platform build validation (amd64 + arm64)