🚀 Auto-PR: Merge test → main - #1017
Merged
Merged
Conversation
The suite reported success while two launch flows were broken. Two independent reasons, both of which had to be fixed for the result to mean anything. printResults tallied only pass/fail/skip/error. Inferno also returns `omit` and `wait`, which fell to a `default:` branch that printed "? OMIT"/"? WAIT" and counted nothing, while still contributing to `total`. The gate was `failed > 0 || total === 0`, so 76 total / 67 passed / 0 failed exited 0 with 9 results in no bucket at all: 5 legitimately omitted TLS tests (local non-TLS mode) and 4 stuck in `wait` because the EHR launch OAuth automation gave up. `omit` and `wait` now have their own counters, an unrecognised status counts as incomplete rather than being ignored, the tally is checked against `total`, and the gate fails on incomplete, unaccounted, or zero tests. Three of the four groups also caught their own errors, logged "WARNING: ... but continuing", and returned null that nothing inspected; the fourth threw, which aborted every group after it. All four now report a structured failure, so one broken group neither hides itself nor suppresses the others, and main() fails on any of them by name. The step summary re-derived its numbers by grepping log markers (which also match the per-poll progress lines) and hardcoded a ✓ beside all four group names regardless of outcome. It now reads the runner's own tally and derives the marks. Verified against the shape of run 31717253615 (67 pass / 5 omit / 4 wait): the new gate fails it and names the 4, a clean run with the same 5 TLS omissions still passes, and an unknown status fails. Expect this to turn the compliance job red until the EHR Launch 500 and the empty patient picker are fixed. That is the point — it was already broken, only silently.
🧪 Auto-PR: Merge `develop` → `test`
The step runs under `bash -e`, so `TOTAL=$(field Total)` aborts the whole step when the tally line is absent — which is precisely the case where the runner crashed before printing it and the summary is the only thing left to read. Verified with the tally line missing: the block now completes and reports zeros.
🧪 Auto-PR: Merge `develop` → `test`
… URL
The 500 was Inferno's, not ours. Its wait message names the launch path in prose:
Tests will resume once Inferno receives a launch request at
`http://localhost:4567/custom/smart_stu2_2/launch` with an `iss` of
`http://localhost:8445/proxy-smart-backend/hapi-fhir-server/R4`.
The runner regex-scraped that bare URL and navigated to it with no query string,
so Inferno had no `iss` to correlate the waiting run with and answered
500 Unable to find test run with identifier ''.
three times, leaving 4 tests stuck in `wait`. The proxy was never in the failing
request — port 4567 is Inferno.
The code comment above the group recorded the inverted assumption ("Inferno then
adds iss and launch params"). In SMART EHR launch the EHR supplies both and the
app echoes `launch` back to /authorize; Inferno is the app here, so the runner
never performed the EHR's half of the handshake at all.
It now does: mint a signed launch code via POST /auth/launch (the flow
signLaunchCode documents), then hand off to Inferno with iss + launch built from
the contract rather than scraped from prose. Because /auth/launch validates
against the default audience set, whose FHIR matcher is a prefix on the proxy's
FHIR base, the token is requested with an RFC 8707 resource indicator, falling
back to a plain token if the realm is not wired for it.
Minting failures degrade to an iss-only handoff with the reason logged, so the
handshake still completes without patient context rather than failing the group.
That should also address the "may not return patient context" note, which was a
consequence of never sending a launch code, not a limitation.
Proxy origin is derived from FHIR_SERVER_URL so the two cannot drift apart.
🧪 Auto-PR: Merge `develop` → `test`
…e handoff With the handoff fixed, the group got as far as 8 passed / 15 total and then sat in `waiting` until the 3-minute timeout, with smart_app_redirect_stu2 never resolving. EHR launch has two phases: the EHR hands the app its launch context, then the app redirects the user to authorize. The loop only served the first — the branch was guarded on `!launchAttempted`, so once the handoff succeeded nothing acted again and the run could only time out. Standalone has no second phase, which is why it never showed this. Adds the authorization phase using the same handling, via a findAuthorizeUrl helper shared in spirit with the standalone path: it prefers a recorded outgoing request over a URL parsed from prose, since parsing prose is what dropped the query string and produced the original 500. Verified against five payload shapes (requests, prose, both, neither, non-waiting) that it keeps query strings and prefers the exact request. When no authorization URL has appeared yet it logs which test ids are blocking, so a persistent stall names its own cause instead of expiring silently.
🧪 Auto-PR: Merge `develop` → `test`
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.
Automated Pull Request 🤖
This PR was automatically created to merge changes from
testintomain.Changes:
Review: Please review the changes before merging.
Last updated: 2026-08-13 19:49:34 UTC