Resource doc#2806
Merged
Merged
Conversation
…erge The upstream merge (b148b1b) re-diverged semantic ResourceDoc fields for v3.1.0 and v4.0.0 because conflict resolution took the upstream side, which had slightly different doc text than Lift's source-of-truth. Re-run scripts/restore_resource_doc_bodies.py to re-align both files: v3.1.0: 8 fields rewritten (2 summary, 2 description, 6 errors, 1 tag) v4.0.0: 50 fields rewritten (5 summary, 47 errors, 7 tags) The merge's important contributions (test fix 14abed0, v2.x Lift retirement, frozen_type_meta_data regeneration, etc.) are preserved. Only the unintended doc-text drift the conflict resolution introduced on the semantic fields is reversed. v2.2.0: upstream commit 71892f5 retired the Lift trait entirely (replaced 1361 lines with a 9-line empty stub), so the audit previously reported v2.2.0 as 0/18 — nothing left in APIMethods220.scala to compare against. Source-of-truth Lift content is preserved in git at 71892f5^. A one-off Python invocation using restore_resource_doc_bodies.py's helper functions extracts the pre-stub APIMethods220.scala from git and runs the same restoration logic against Http4s220.scala: v2.2.0: 15 fields rewritten (13 descriptions, 1 example, 1 success body) Two imports added to Http4s220.scala (Glossary and java.util.Date) so the restored descriptions / example bodies compile (Lift had them in scope via APIMethods220's broader import set; the http4s stub had a leaner set). Audit after this commit: v2.2.0: 0 of 18 mismatched (3 only-http4s are URL renames for NEW_ACCOUNT_ID / VIEW_ACCOUNT_ID / UPD_VIEW_ID middleware bypass — measured against pre-stub Lift) v3.1.0: 5 mismatches (all middleware URL renames) v4.0.0: 20 mismatches (mostly middleware URL renames + 1 verb fix) Total mismatches across migrated versions: 128 (was 144 before v2.2.0 restoration; v2.2.0 was previously marked "not started" since the audit couldn't see the retired Lift content). LIFT_HTTP4S_MIGRATION.md updated with v2.2.0's row + per-endpoint fix-candidate table. Per the source-of-truth rule, none of the APIMethodsXYZ.scala files are modified.
Run scripts/restore_resource_doc_bodies.py against the three remaining
"untouched" versions to bring them in line with their Lift source-of-truth.
Per-version rewrite counts:
v1.2.1: 62 fields (1 summary, 41 description, 1 success body, 20 errors)
v2.0.0: 23 fields (19 description, 1 example body, 3 errors)
v2.1.0: 17 fields (1 summary, 12 description, 1 example body, 2 errors, 1 tag)
Supporting code carried over from APIMethodsXYZ.scala into the matching
Http4sXYZ.scala so restored descriptions compile:
v1.2.1 (Http4s121.scala):
+ private val generalRevokeAccessToViewText (verbatim from
APIMethods121.scala:906) — referenced by revoke-access descriptions.
v2.0.0 (Http4s200.scala):
+ import alias `AmountOfMoneyJSON121` for AmountOfMoneyJsonV121
(used inline in createAccount's example body).
+ 3 private vals for createUserCustomerLinks entitlements text
(createUserCustomerLinksEntitlementsRequiredForSpecificBank,
...ForAnyBank, ...requiredEntitlementsText) — referenced by
restored description.
v2.1.0 (Http4s210.scala):
+ import code.sandbox.SandboxData (used in sandbox-data-import
example body).
+ private val getTransactionTypesIsPublic (Props lookup) — used by
${userAuthenticationMessage(!getTransactionTypesIsPublic)} in the
restored description.
+ private val createCustomeEntitlementsRequiredText — alias of the
correctly-named createCustomerEntitlementsRequiredText. Lift's
APIMethods210.scala has a typo (missing the `r` in "Custome"),
and the restored description interpolates the typo'd name. We
preserve the bug-for-bug name to keep the restoration verbatim.
Audit after this commit:
v1.2.1: 48 → 6 mismatches (all middleware URL renames)
v2.0.0: 19 → 1 (1 middleware URL rename)
v2.1.0: 13 → 1 (1 middleware URL rename) plus 5 only-lift + 2 only-http4s
(transaction-request-type variants — separate workstream)
Grand total across all versions: 128 → 60 mismatches.
Per the source-of-truth rule, none of the APIMethodsXYZ.scala files
are modified.
LIFT_HTTP4S_MIGRATION.md updated with the new per-version rows.
…21 endpoints
CI test reports (shard2(1), shard3(1), shard4(6)) flagged a recurring
class of failures: unauthenticated requests get 401 / 403 where the
handler's actual auth model says 200 / 201 / 401.
Root cause is the same in all cases. Lift's `APIMethodsXYZ.scala`
files (the ResourceDoc parity source-of-truth per CLAUDE.md) have
descriptions or errorResponseBodies that disagree with the actual
Lift handler's auth behaviour. In Lift's runtime this didn't matter —
`OBPRestHelper` doesn't enforce ResourceDoc errors at dispatch — but
http4s's `ResourceDocMiddleware` derives `needsAuthentication` from
both the errors list and the description's `authenticationIsOptional`
marker, so contradictory docs land the wrong status code.
Fixed endpoints (intentional drifts from Lift's source-of-truth,
commented at each site):
v3.1.0 (2 already fixed earlier in `14abed06c`, re-broken by the
restoration in `83a2f25c4`, re-applied here):
- getTransactionByIdForBankAccount: description (false)→(true)
- getObpConnectorLoopback: description (true)→(false)
v2.0.0 (1):
- createUser: removed `AuthenticatedUserIsRequired` from errors
(handler is anonymous; Lift's errors list lies)
v1.2.1 (18):
Anonymous endpoint with auth-required error: removed it
- publicAccountsAtOneBank: removed $AuthenticatedUserIsRequired
View-gated endpoints with auth-required handler but description /
errors said optional. Either added $AuthenticatedUserIsRequired to
errors, or flipped description userAuthenticationMessage(false)→(true),
or both, to make `needsAuthentication=true`:
getOtherAccountByIdForBankAccount, addCounterpartyPublicAlias,
updateCounterpartyPublicAlias, deleteCounterpartyPublicAlias,
getOtherAccountPrivateAlias, addOtherAccountPrivateAlias,
updateCounterpartyPrivateAlias, deleteCounterpartyPrivateAlias,
updateCounterpartyImageUrl, deleteCounterpartyImageUrl,
addCounterpartyOpenCorporatesUrl,
getTransactionNarrative, addTransactionNarrative,
updateTransactionNarrative,
getTagsForViewOnTransaction, deleteTagForViewOnTransaction,
getWhereTagForViewOnTransaction,
getOtherAccountForTransaction
Per the source-of-truth rule, APIMethodsXYZ.scala files are NOT
modified — the drift lives on the http4s side with an explanatory
comment on each pair (the v3.1.0 and v2.0.0 changes carry the
comment; the 18 v1.2.1 changes are a programmatic batch and the
overall intent is captured here in the commit message).
…lse)→(true) shard3(2) CI report shows 18 of 19 v1.2.1 failures from the previous run (b86e2f1) are resolved; addTransactionNarrative still returns 403 for unauthenticated requests instead of 401. The previous fix added \$AuthenticatedUserIsRequired to the errors list, but the description still had userAuthenticationMessage(false). The ResourceDoc constructor strips \$AuthenticatedUserIsRequired from errors when the description carries `authenticationIsOptional`, so my error-list addition was silently undone. Flip the description marker to (true) so the constructor leaves \$AuthenticatedUserIsRequired in place → middleware enforces 401 for unauthenticated requests, as the handler intends. accountById has the same (false) flag in its description, but it's a genuinely conditional endpoint (anonymous OK on public views, auth required on private views) and has not surfaced as a test failure; leave it alone. Per the source-of-truth rule, APIMethods121.scala is not modified.
|
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
2 participants
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.
No description provided.