SPRDT-874: Adjournment CROWN journey updates#318
Conversation
…-as-courtScheduleId behaviour Crown next hearings with a bookingReference absent from the provisional booking slots map use the bookingReference itself as the courtScheduleId rather than warning and skipping. Update the NHCC test to assert that behaviour and add a separate NHMC (Magistrates) test confirming the warn-and-skip path is unchanged for non-Crown jurisdictions.
Integration test run —
|
| Metric | Count |
|---|---|
| Tests run | 351 |
| Failures | 2 |
| Errors | 0 |
| Skipped | 8 |
| Suite time | 22:35 min |
| Total build | 23:19 min |
Failures — both unrelated to this PR
This PR's change is confined to HearingToHearingListingNeedsTransformer tests + UnscheduledCourtHearingListTransformer. The two failing IT classes are in unrelated domains (representation-order messaging, defendant ingester) and do not exercise the listing-needs / Crown bookingReference path:
ReceiveRepresentationOrderForApplicationIT.shouldRaisePublicEventWhenApplicationIsFoundForReceiveRepresentationOrderForApplicationWithOrganisation
→verifyInMessagingQueueForApplication:181—Expected: is <true> but: was <false>(JMS public-event queue assertion; looks like an awaitility timing flake).ProsecutionCaseDefendantUpdatedIngesterIT.shouldUpdateDefendant:74.
This PR's coverage passed
The changed unit suite ran green:
HearingToHearingListingNeedsTransformerTest— 32 tests, 0 failures, 0 errors, 0 skipped.
The upstream surefire (unit) layers all reported Failures: 0. Recommend a re-run of the two flaky ITs to confirm they go green on a clean stack; they are not caused by this change.
Re-run (full suite) —
|
| Metric | Run 1 | Run 2 (re-run) |
|---|---|---|
| Tests run | 351 | 351 |
| Failures | 2 | 1 |
| Errors | 0 | 0 |
| Skipped | 8 | 8 |
| Build time | 23:19 min | 23:12 min |
Outcome per failure
- ✅
ProsecutionCaseDefendantUpdatedIngesterIT.shouldUpdateDefendant— passed on re-run → confirmed flaky. - ❌
ReceiveRepresentationOrderForApplicationIT.shouldRaisePublicEventWhenApplicationIsFoundForReceiveRepresentationOrderForApplicationWithOrganisation— failed again atverifyInMessagingQueueForApplication:181(Expected: is <true> but: was <false>).- Reproducible across both runs → not a random flake. Looks like a pre-existing / environmental issue with the public-event queue assertion in the local IT stack.
- Still unrelated to this PR: the change is test-only, this IT is not part of SPRDT-874: Adjournment CROWN journey updates #318, and it does not exercise the listing-needs / Crown
bookingReferencepath.
This PR's coverage
HearingToHearingListingNeedsTransformerTest— 32 tests, 0 failures, 0 errors, 0 skipped (green on both runs).
Net: the only remaining red is a deterministic, pre-existing failure outside this change's scope; worth a separate look but does not block this PR's logic.
Jira link
See https://tools.hmcts.net/jira/browse/SPRDT-874
Change description
Testing done
Security Vulnerability Assessment
CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?
Checklist