[wshallwshall]

Batch 294 (auth), item #3350. A separate PR from batch 294's #3339/#3282 PR, because that one carries a security-control change and gets its own.

Merge danger -- #3350

Reversible: yes -- a revert on main undoes all of it.

Blast radius: the text of the direct-build removed-key refusal (_removed_key_message in messagefoundry/config/settings.py), which security show and security set print when a removed [security] key is set in the file. No other behaviour changes; the refusal still refuses.

Evidence -- #3350

• Before: at main 6d6986fdd, security show with [security].handles_real_patient_data or [security].require_sign_in set in the file exits 1 and prints "The key was passed straight to the section, so no environment variable set it." That holds even when the service environment also sets the key, so the claim can be false.
• After: the refusal reads "Remove <key> from the arguments or the file table the section was built from" and makes no claim about the environment. tests/test_security_cli.py runs security show for each removed [security] key with the key in the file, then with the matching variable set as well, and asserts: rc=1 and identical output in both runs, the removal step directly follows the reason, and no "environment variable" in any case. A second test sets the variable alone and checks the partial reason names MEFOR_SECURITY_<KEY>. Mutation checks: the old wording, a reworded claim before the removal step, and a claim after it each fail 8 tests.

---

Source branch

b294-3350, head cf962a3b9a1ce0e2a2cd1178caa67b894a9547b1, on main 6d6986fdd. Commits 977d66d31, 70c1e9d80 (corrects a false statement in the round-1 commit message), cf962a3b9. git merge-tree against PR 2387's head and against batch 294's other branch both exit 0.

Builder report (summarised by the Manager)

Closing step 1, the trace (security show --json, for each removed key, in the file and in the environment):

• The false claim appeared in one case only: [security].handles_real_patient_data or [security].require_sign_in set in the file (rc=1, invalid [security] in <path>: ...). show builds SecuritySettings straight from the file's [security] table, and that is the direct-build refusal.
• The same two keys set only in the environment: rc=0; the partial reason names MEFOR_SECURITY_<KEY>.
• The other four keys ([ai].data_class, [api].serve_ui_explicit, [auth].enabled, [pipeline].require_rcsi_for_pooled), in the file or in the environment: rc=0, with the loader's text naming both. No false claim.
• Key in both file and environment: same output as file-only, so the old text printed the false claim.
• security set gives the same direct-build refusal through its precheck.

Checks:

• ruff check "All checks passed!"; ruff format --check "3 files already formatted".
• mypy all four legs before the review repairs: linux "no issues found in 361 source files", win32 "342", tests "1387", scripts/asvs "6". After the repairs (test and docstring edits only), mypy on the changed files: tests "no issues found in 2 source files", win32 settings.py "no issues found in 1 source file".
• pytest on test_security_cli, test_open_mode_is_no_service, test_cli_settings_error_render, test_settings_env_keys, test_security_config, test_settings: "511 passed, 1 warning".
• Changelog fragment check "416 well-formed, 0 malformed"; fragment changelog.d/3350.fixed.md.
• Not run: the full suite. Read the full test legs on this PR.

Shipped open (code review, for rows)

1. Raised in both review rounds: security show and security set already compute the loader's refusal, which names the variable, in the same run, and throw it away on the removed-key error path. The fix would be in __main__.py around lines 10606-10612 and 10643: print the loader's _removed_key_message(section, key, reason) form, or emit _loosenings_partial_reason beside the error. Not done here, because the brief preferred removing the false claim and kept hunks out of __main__.py, where PR 2387 is active. Closing step 2 allows either route.
2. Pre-existing: the removal step still says "from the arguments", which means nothing to a show user.
3. Pre-existing: the _refuse_removed_keys docstring (settings.py around line 433) advises removing the key with security set and a null value. Measured: when the shell environment also sets the key, that edit is refused and the file keeps the line.
4. No test runs security set with a removed key in the file.

Claim on #3350 is still held by the Builder's worktree (it left it for open finding 1).

Proposed vault banner (the Lander's to flip)

• #3350: CLOSED by engine PR . The direct-build refusal for a removed key, which security show and security set print for a [security] key in the file, no longer claims that no environment variable set it; tests run security show with the key in the file, with and without the variable, and with the variable alone.

[wshallwshall]

QA line, BUILDER.md step 11, posted by the Manager from the Builder's report as given (BACKLOG #3350, head cf962a3b9a1ce0e2a2cd1178caa67b894a9547b1):

I ran the code-review skill twice, at level xhigh both times, with the brief's exact arguments. It printed no tag either time, only a JSON findings array: 14 findings in round 1 and 9 in round 2. Both rounds were repaired, which reaches the cap.

Applied: positional and whole-step pins in place of the single phrase check, and case-insensitive needles; a same-output check between the file-only and file-plus-environment runs; an assert that the key list is not empty, and separate asserts in place of one joined assert; the docstring names security set as well and no longer contradicts itself; changelog scope widened and put in the conditional (section 0); two false statements removed from the test comments; the round-1 commit message's false statement corrected by 70c1e9d.

Shipped open: the four items under "Shipped open" in the PR body.

[wshallwshall]

Lander: enqueued at cf962a3, pinned. The QA line names this head (code-review at xhigh, twice). The four shipped-open findings are filed as vault #3885 in open vault PR 2543. Graded non-blocking: three are pre-existing or a test gap, and item 1 waits on engine PR 2387. None changes behaviour against main or weakens a control. That grade is a Lander decision under the owner's Driver delegation, not an owner ruling. All 9 live required contexts are SUCCESS on this head.

[github-actions]

CI failed in web console tests (windows-2025, py3.14) / Web console tests (pytest) while this pull request was in the merge queue, so the queue ejected it.

Its own head can still be green: the queue revalidates the merge, and the path gates that skip on a pull request run there. Read the run before retrying.

https://github.com/MEFORORG/MessageFoundry/actions/runs/39328582619

[wshallwshall]

Manager triage of the merge-queue ejection, run 39328582619 (gh-readonly-queue/main/pr-2436-45c5ebcf, merge SHA c365c4c0475f), PR head cf962a3b9a1ce0e2a2cd1178caa67b894a9547b1.

• Result: web console tests (windows-2025, py3.14), 1 failed, 1095 passed. The failure is packaging/messagefoundry-webconsole/tests/test_ui_dr_outlive.py::test_a_console_release_cut_off_by_the_deadline_still_completes, line 76: coord.active was still True after outliving_operations.inflight drained, with the request deadline set to 0.2 s.
• This PR changes one refusal string in messagefoundry/config/settings.py plus two test files. It touches no DR, web console or request-timeout code.
• That test does not appear in the failed logs of the other 24 of the 25 most recent failed ci.yml runs, including the PR 2434 queue group just ahead of this one. Control: the same read finds other FAILED lines in 23 of those 24.
• Reading: a one-off timing failure on the Windows runner, not caused by this diff. No code change pushed. Re-enqueue is the Lander's; a second red on the same test would be a finding, not a flake.

[wshallwshall]

Lander: re-enqueued at cf962a3, the same pinned head, as the one rerun the flake policy allows. The eviction (run 39328582619) was test_ui_dr_outlive::test_a_console_release_cut_off_by_the_deadline_still_completes on web console windows-2025, 1 failed / 1095 passed. That is the deadline race filed as vault #3871, which hit engine PR 2387 on ubuntu today. This PR touches no DR or web console code. If it evicts again on the same test, it is routed as a real failure.