Add bencher_run keys to API seed test

[epompeii]

This changeset adds bencher_run keys to the API seed test as a follow on to #823

[github-actions]

🤖 Claude Code Review

PR: #829
Base: devel
Head: u/ep/seed-key
Commit: 5b11285bc92913d39e0b069fa2ecbbd8397383af

---

Here's my review of the PR:

---

PR Review: key_seed_test

Summary

This PR adds integration test coverage for project-scoped bencher_run keys (from PR #823). It covers:

1. Creating a project key and immediately using it for bencher run
2. Exercising key-based auth in the 30-iteration benchmark loop (alternating with token auth)
3. Using the project key for a feature-branch run
4. Full CRUD lifecycle: list, view, update (rename), revoke, and revoke-idempotency check

Positives

• Thorough coverage: The CRUD lifecycle is well tested — create, list, view, update, revoke, verify revoked key returns 401, verify revoked key hidden from default list, verify --revoked flag surfaces it, and double-revoke fails.
• Good test matrix in the loop: Expanding from 2 to 4 rem_euclid branches gives good interleaving of key vs. token auth and hash vs. no-hash, single-string vs. separate-args command forms.
• Security-relevant assertion: Verifying that a revoked key returns 401 is important.

Issues

1. Hash cadence change in the 30-iteration loop (potential behavioral concern)

Previously, hashes were supplied on even iterations (i % 2 == 0), meaning 15 of 30 runs had hashes. Now hashes are supplied on i % 4 == 0 and i % 4 == 2, which is still 15 of 30 — so the count is the same, just the distribution across key/token is different. This is fine.

However, the pairing changed: previously hash was always paired with single-string commands and no-hash with separate args. Now the pairings are:

• % 4 == 0: key + hash + single-string
• % 4 == 1: token + no hash + separate args
• % 4 == 2: token + hash + single-string
• % 4 == 3: key + no hash + separate args

This is a good expansion of the test matrix — no issue here.

2. Fragile contains("Status: 401") assertion (lines ~1063-1066 in the diff)

assert!(
    String::from_utf8_lossy(&output.stderr).contains("Status: 401"),
    "revoked project key should 401: {output:?}"
);

This relies on the exact CLI error message format. If the error rendering changes (e.g., status: 401, HTTP 401, or a structured error), this test silently passes on the wrong thing or breaks for cosmetic reasons. Consider whether there's a more robust way to assert the exit code + status, or at minimum check for both "401" and "Unauthorized" as a belt-and-suspenders approach.

3. No test for updating a revoked key

The test verifies that double-revoke fails, but doesn't test whether update on a revoked key succeeds or fails. Depending on the desired API semantics, this could be worth covering.

4. Missing --project flag validation with --key

The initial bencher run with the project key (line ~626) passes --project the-computer, but project keys are already scoped to a project. The test doesn't verify what happens when --project is omitted (should it be inferred from the key?) or when a mismatched --project is provided. This may be out of scope for this PR but worth tracking.

5. Minor: project_key_uuid_str as String instead of using the UUID directly

let project_key_uuid_str = project_key_created.uuid.to_string();

This is converted to &str at every call site. Per CLAUDE.md guidance to "pass strong types instead of stringly typed equivalents," consider keeping project_key_created.uuid and calling .to_string() inline, or check whether the CLI args accept a UUID type directly. This is minor since it's test code and the CLI fundamentally takes string args.

No Issues Found

• Security: Key material is properly scoped, revocation is tested, 401 on revoked keys is verified.
• Performance: No concerns — this is test code.
• CLAUDE.md compliance: Uses #[expect(clippy::indexing_slicing)] correctly, uses constants for repeated strings, uses thiserror-compatible patterns.

Verdict

The PR is solid. The only actionable item is #2 (fragile status code assertion) — worth hardening. Items #3 and #4 are nice-to-haves for follow-up.

---

_{Model: claude-opus-4-6}

[github-actions]

Bencher Report

Branch	u/ep/seed-key
Testbed	intel-v1

Click to view all benchmark results

Benchmark	Latency	Benchmark Result microseconds (µs) (Result Δ%)	Upper Boundary microseconds (µs) (Limit %)
Adapter::Json	📈 view plot 🚷 view threshold	4.60 µs (+1.25%) Baseline: 4.55 µs	4.73 µs (97.23%)
Adapter::Magic (JSON)	📈 view plot 🚷 view threshold	4.48 µs (+1.40%) Baseline: 4.42 µs	4.61 µs (97.22%)
Adapter::Magic (Rust)	📈 view plot 🚷 view threshold	25.34 µs (-0.04%) Baseline: 25.35 µs	26.30 µs (96.38%)
Adapter::Rust	📈 view plot 🚷 view threshold	3.48 µs (+1.14%) Baseline: 3.44 µs	3.58 µs (97.18%)
Adapter::RustBench	📈 view plot 🚷 view threshold	3.47 µs (+1.14%) Baseline: 3.43 µs	3.56 µs (97.45%)

🐰 View full continuous benchmarking report in Bencher