Fix: adapt to ScopeRef generalization, repoint CI/release at dev - #2
Merged
Conversation
…e at dev Core's admission model landed the generic-admission-topology change (busbarAI dev@33bf1a7, d7d1a81): VirtualKey.allowed_pools -> allowed_scopes: Option<Vec<ScopeRef>>. Wire/DB format is unchanged (still a plain JSON array of pool-name strings in the `allowed_pools` column), so only the Rust-side conversion at this crate's boundary changes: ScopeRef::pool(name) at construction, .value at read. Also: ci.yml was pinned to the reusable plugin-ci workflow's stale default (@1.5.0-dev, a branch that predates the generic-credentials redesign this plugin's own code already requires) with no busbar_ref override -- repointed to @dev with an explicit busbar_ref: dev. release.yml's frozen BUSBAR_REF SHA bumped to current dev (d7d1a81) for the same reason. Verified against a clean, isolated origin/dev worktree (not the shared local checkout) and a live postgres:16 container: 13 tests pass (10 unit + 3 e2e), fmt/clippy clean on both crates.
MattJackson
added a commit
that referenced
this pull request
Aug 6, 2026
…ns a failed boot
This harness spawned every busbar with `.stdout(Stdio::null())` and
`.stderr(Stdio::null())`, so when a boot failed the entire report was
boot #1 exited before its admin listener came up (status: exit status: 1)
An exit code and nothing else. busbar had already printed a precise,
actionable diagnosis; this test deleted it at the moment it was produced.
That is not hypothetical. qa-gate run 31059945604 lost this leg, and the
cause could not be read from this test's own output at all. It had to be
recovered from a DIFFERENT job's logs, which happened to boot busbar
against a similar config and did not null its stderr. The reason was:
[error] config.yaml: this looks like a busbar 1.x config ...
- `auth.admin_auth:` carries INLINE module entries (retired 1.5.3 ->
define the provider once under `identity-providers:` and reference
it by bare name)
busbar 1.5.3 makes retired config keys a fail-closed boot refusal, and the
gate was cloning this repo at `main`, which still carried the pre-1.5.3
fixture. A test whose only failure mode is "it exited" cannot be debugged
from its own output, whatever the underlying bug turns out to be.
So: every boot now redirects stdout+stderr to a file under the test's work
dir, `ChildGuard` carries that path, and EVERY failure path prints it -- the
admin-listener poll (both the early-exit and the 15s-deadline arms), the
boot #2 schema poll, and the boot #2 `booted` assertion. The deadline arm
was an `assert!` with no output; it is now a `panic!` that dumps the log,
because a busbar that hangs rather than exits is exactly as opaque as one
that exits.
A FILE rather than `Stdio::piped()`, deliberately: nothing here reads the
pipe while the child runs, so a child that out-talked the pipe buffer would
block forever on write, turning a clean failure into a hang.
Proven red-before-green against a real postgres:16 container and a busbar
built from core HEAD. With the fixture reverted to the retired inline
`auth.admin_auth` form the test now fails with busbar's full refusal
inlined in the panic; restored to the 1.5.3 `identity-providers:` form it
passes. Both boots exercised, 207s.
MattJackson
added a commit
that referenced
this pull request
Aug 6, 2026
…happened The file-drop e2e's boot proof polled the SHARED test database for the `keys` table. Every live unit test in this workspace opens a PostgresStore, and connect() migrates, so that table already existed by the time the e2e binary ran: the poll broke true on its first iteration, before the child-exit check, even if busbar had failed to load the plugin and exited immediately. It now boots against a disposable database created empty for that test alone, so the schema it finds can only have come from the boot under test, and it goes on to read back the schema version that boot wrote and confirm the process is still running rather than having died after migrating. The dead key id it declared and cleaned up without ever writing is gone with it. The unauthenticated-install check accepted any non-status error as proof the token guard held. That request never runs error_for_status, so `is_status()` is false for every error it can produce, connection-refused included: a server that had already crashed read as a successful rejection. It now proves the server is still answering, so a deliberate reject is the only explanation left. Also corrects the admin-API test's comment, which called its own shared-database poll the only genuine confirmation that boot #2 loaded the plugin. The genuine confirmation is the mint further down, verified by reading the key and credential rows back over a raw client.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Test plan