PEG-3447 Decouple sjp from material-client - #133
Open
allanmckenzie wants to merge 1 commit into
Open
Conversation
Copy material's material-client HTTP adapter into sjp as a self-contained class so sjp no longer compiles the shared material-client JAR, removing the "material must release first" constraint. Runtime behaviour is unchanged - sjp still calls material over HTTP exactly as before. - Add a trimmed, self-contained MaterialClient in sjp-query-api (uk.gov.moj.cpp.sjp.material.client): only the getMaterialWithHeader method sjp uses, injected logger. 100% unit coverage. - Remove the material-client JAR dependency from sjp-query-api; update the consumer import and the resource test's never()-verify to the new type. - Keep the material-query-api:raml contract artifact. - Bring stale interface pins to latest released so the MoJ-latest-interfaces enforcer passes: material 17.0.85, referencedata 17.104.140, progression 17.0.286. Full unit build green; sjp integration suite 251/254. The 3 remaining failures (CaseUnassignmentIT, DefendantAcceptedAocpIT, MultipleOffencesWithdrawalRequestedIT) are a pre-existing IT-harness issue - an async AOCP-notification flow gets a 404 from an unmatched referencedata /prosecutors stub, unrelated to this change (that flow does not use MaterialClient; the /prosecutors contract is identical between referencedata 17.104.137 and 17.104.140).
allanmckenzie
requested review from
MrDudCowan,
khajahasanshaik and
madjava
and removed request for
a team
August 11, 2026 21:03
|
|
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.
What & why
materialpublishes a small hand-written Java library (material-client) thatsjpcompiles directly into its build, forcingmaterialto release beforesjpcan complete its Java upgrade. This PR givessjpits own copy of the adapter (Option B from the decoupling plan).Runtime behaviour is unchanged —
sjpstill callsmaterialover HTTP exactly as before.Changes
MaterialClientinsjp-query-apiunderuk.gov.moj.cpp.sjp.material.client— trimmed to the single method sjp uses (getMaterialWithHeader), injected logger. 100% unit coverage.material-clientJAR dependency fromsjp-query-api; updated the consumer import and the resource test'snever()-verify to the new type.material-query-api:ramlcontract artifact.material 17.0.85,referencedata 17.104.140,progression 17.0.286.Testing
MaterialClientbean resolves and invokes correctly in the deployed WAR, and all material / document-content IT paths pass.Pre-existing IT flakiness (not caused by this change)
The small, shifting set of remaining IT failures is pre-existing harness/environment flakiness on our local stack, unrelated to this change (the affected flows don't use
MaterialClient, and the/prosecutorscontract is byte-identical between referencedata17.104.137and17.104.140). Two clusters, for the owning team:/prosecutors404 race (CaseUnassignmentIT,MultipleOffencesWithdrawalRequestedIT,FilterSessionByProsecutorIT). The asyncPartialAocpCriteriaNotificationProcessorcallsgetProsecutorvia the frameworkRequester, which emits a doubledAcceptheader (…prosecutors+json, …prosecutors+json). The catch-all stubReferenceDataServiceStub.stubQueryForAllProsecutors()matches withwithHeader(ACCEPT, equalTo(mime)), which fails against the doubled header → async bleed-over prosecutor queries 404 → JMS rollback → stream stall. Suggested fix (verified locally to drop 404s from ~18k → 0): change that matcher tocontaining(mime). Not applied here, to keep this PR scoped to the material decoupling.AssignmentHelper … within 10 seconds,decision-saved not present,SearchCasesITES reflection). Event → viewstore/ES projection intermittently exceeds the tests' 10s/awaitility windows on our local stack (much slower than CI). Expected to pass on the team's CI.Tracking: PEG-3447 (epic PEG-3295, Java 25 upgrade).
🤖 Generated with Claude Code