Reconcile MISMATCH wire DTOs (issue #53) — backend half#61
Open
johardi wants to merge 6 commits into
Open
Conversation
Two backend records used JSON field names that diverged from the canonical `changeRequestId` used by every other ContentChangeRequest implementer: EditAnnotationsAction (`contentChangeRequest`) and MergeUploadedProjectAction (`changeRequesId` — typo). Both showed up in the MISMATCH bucket of the wire-DTO conformance audit (#53) because the gwt-ui client expects the canonical name. Renaming the JSON property aligns these records with the rest of the wire contract; the Java component name is unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
#52 pinned @JsonProperty on the FRAGILE bucket but skipped records whose audit pair was already classified as MISMATCH. These 12 records still have naked record components, so a Java rename would silently break the wire contract once the gwt-ui client side of #53 lands. Pinning here uses the existing JSON name (= the record component identifier) so no behavior changes today; it just locks the wire field name against future renames and makes the contract greppable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ents #52 pinned @JsonProperty on the FRAGILE bucket but skipped events whose audit pair was already classified as MISMATCH. These 9 ProjectEvent records still have naked components, so a Java rename of `eventId`/`projectId` would silently break the wire contract once the gwt-ui client side of #53 lands. Pinning uses the existing component name as the JSON name (no behavior change today); it just locks the wire field name against future renames and makes the contract greppable alongside the rest of the events from the FRAGILE pin. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sub-pattern 3 of #53: per-class structural mismatches. Pinning the JSON name of the backend record components so the wire contract is locked once the gwt-ui client side of #53 renames/restructures to match. The chosen JSON names follow the backend canonical (per the issue body, "pick the canonical name (usually backend)"): - GetEntityUsageAction: subject, projectId, usageFilter, pageRequest - GetProjectEntityGraphDefaultEdgeCriteriaResult: edgeCriteria - GetHierarchySiblingsResult: siblingsPage - GetHeadRevisionNumberResult: projectId, revisionNumber - GetRevisionSummariesAction: projectId, pageRequest - GetRootOntologyIdResult: projectId, rootOntologyId - CreateNewProjectAction: newProjectId, newProjectSettings - GetProjectSharingSettingsResult: settings - SetProjectSettingsAction: changeRequestId, projectId, settings - SetProjectSettingsResult: settings No JSON name changes today; the client PR coordinates the structural fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ponents Two backend records (SetAnnotationValueAction, AddProjectTagAction) had at least one naked record component the FRAGILE pin in #52 missed, surfaced by the conformance re-audit run as part of #53. Pinning each record component with @JsonProperty using the existing JSON field name (no behavior change). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The record components were naked (only the static factory had @JsonProperty); the conformance audit re-run during #53 flagged it as FRAGILE. Pinning the record components matches the rest of the events that #52 already covered. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Backend half of the coordinated pair for #53. The companion client-side changes live in webprotege-gwt-ui#274; the two should land together.
What's changing
The backend exchanges messages with the gwt-ui client as JSON. Each field has a name on the wire — but for a chunk of our DTOs, that name was never written down explicitly. Jackson was happy to infer the JSON name from the Java field name, which worked fine until someone renamed a Java field (the wire silently broke) or until the two repos drifted apart on what name to use (the field silently dropped).
This PR locks down the wire names on the backend side. Concretely:
Two fields had the wrong name and are renamed. Both were special cases of
changeRequestId— one had a typo (changeRequesId), and one used a completely different name (contentChangeRequest) than every other class that carries the same field. Renamed so the client and backend agree. See d93ef1e.The remaining records get an explicit
@JsonProperty("…")on every component. This doesn't change the wire today — it just tells the compiler and the next reader exactly what the JSON name is supposed to be, so a future Java rename can't silently break the contract. Issue 52 did this for one bucket of classes; this PR finishes the rest (the Actions, Results, and Events that were skipped because they were already known to disagree with the client). See ac099c6, e538e6f, f9d9d7b, f9b4b1d, 99b2439.Why now
Until the companion PR in
webprotege-gwt-uilands, these annotations are a pure cleanup — they describe what we already do. Once the client PR lands, the two sides finally agree on the field set for every message they exchange. That fixes a quiet category of bugs where caller-supplied data (change-request ids, page requests, project ids, event ids) was being dropped on the wire and silently regenerated server-side.Test plan
mvn -DskipTests compilesucceeds.Crosslink
protegeproject/webprotege-gwt-ui#274