fix: three Portal and API-Manager calls to endpoints OBP-API does not serve - #6
Open
hongwei1 wants to merge 2 commits into
Open
Conversation
Each was found by resolving every call site in this repository against OBP-API's published resource-docs, and each was confirmed against a live develop-obp (3df73fe11) with the verb held constant, so none of them is the 404-for-a-wrong-verb ambiguity. Portal, accepting a user invitation (#5) obp_requests.put -> post. /obp/v4.0.0/banks/{id}/user-invitation is POST-only at v4.0.0 and v6.0.0 alike; PUT answers 404 OBP-10404 while POST answers 401. The same file already POSTs the sibling /user-invitations path correctly, and API-Manager POSTs this one correctly, so the convention was established in two other places and only this call site diverged. Fixing the verb alone did not make the flow work, which the new test caught: the redirect was thrown inside the try, and the catch-all below it turns anything that is not an OBPRequestError into "Failed to create account: Unknown error". redirect() signals by throwing, so a successful account creation reported failure. The redirect now returns after the try/catch, matching what the register action already does. Portal, removing a chat reaction (#6) The emoji moves from the DELETE body into the path: OBP-API serves .../reactions/{emoji} for DELETE and only POST/GET on .../reactions. The response is now checked with res.ok, mirroring the add branch immediately below it. fetch does not reject on 4xx, so the old try/catch could not see the failure -- the reaction vanished from the UI, stayed in the database, and returned on reload with nothing logged. The add path was already correct and is untouched. API-Manager, creating a custom view (#7) routes/backend/obp/banks/[bank_id]/views/+server.ts is deleted rather than repaired. It targets /obp/v6.0.0/banks/{id}/views, which OBP-API does not serve at any verb -- every view endpoint is account-scoped -- and nothing calls it: the custom-view page posts to the account-scoped route next to it, which builds the correct URL. It was a copy of a working route with the account segment dropped. Adds apps/portal/src/routes/user-invitation/page.server.test.ts, following the pattern of the register action's test. It asserts the verb rather than only the URL, which is what lets it fail if this regresses, and it is what surfaced the swallowed redirect. Verified: portal 86/86 unit tests pass, api-manager 15/15. svelte-check is unchanged against the base commit on both apps (portal 21 errors/70 warnings, api-manager 22/332), so no new type errors. Both apps build.
The reaction fix shipped without a test, which left the least visible of the three
defects the least protected: fetch resolves on a 4xx, so the failure it guards
against produces no error anywhere -- the reaction vanishes from the UI, stays in
the database, and returns on reload.
Three cases, rendered against the real component:
* removal sends the emoji as the last path segment and no body;
* a failed removal restores the badge, which is the res.ok check;
* addition still POSTs with the emoji in the body, unchanged -- that path was
already correct and the test exists to keep it that way.
Both new cases were run against the pre-fix code and fail there: the first on the
URL, the second on the badge staying gone. The third passes either way, as it
should, since the add path was not touched. A test that has not been shown to fail
does not establish anything when it passes.
$env/dynamic/public is mocked because the component pulls in $lib/avatar/generate,
which reads it at module scope and throws under vitest otherwise.
portal is now 89/89 across 11 files.
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.
Three calls in Portal and API-Manager went to endpoints OBP-API does not serve. Each one
failed silently in a different way, which is why none of them had been noticed:
1.
user-invitationaccepted withPUT, and swallowed the result.obp_requests.putwas called against/banks/{id}/user-invitations, which OBP-API servesas
POSTonly. The response was never checked, and theredirectsat inside thetry, soSvelteKit's control-flow redirect was caught by the same
catchthat handled the API error.The user saw a success page after a failed request. Fixed the verb and moved the redirect
out of the
try.2. Chat reaction removal put the emoji in the body.
DELETE .../messages/{id}/reactionswith{ emoji }as a JSON body. The API serves theemoji as the last path segment —
.../reactions/{emoji}— and.../reactionsisPOSTandGETonly. The UI removed the reaction optimistically and never checkedres.ok, so a 4xxleft the reaction gone from the screen, still in the database, and back again on reload,
with nothing logged. Fixed the path and added the
res.okrevert.3. API-Manager had a proxy route for an endpoint that does not exist.
backend/obp/banks/[bank_id]/views/+server.tsproxiedGET /banks/{id}/views. OBP-API hasno such endpoint — views are per-account (
/banks/{id}/accounts/{id}/views) or system-wide(
/system-views). Nothing in the app called this route. Removed.Tests
Added coverage for the two behavioural fixes:
apps/portal/src/routes/user-invitation/page.server.test.ts— asserts the verb, notjust the URL, and that a failing API call does not produce a success redirect.
apps/portal/test/unit/routes/chat.reactions.svelte.test.ts— asserts the emoji is a pathsegment, that no body is sent, and that a 4xx reverts the optimistic removal.
npm run test:unitinapps/portal: 89 passed / 11 files, on top of currentmain.These three were found by diffing the front ends' actual call sites against OBP-API's
resource-docs surface, so each is a real mismatch against what the API advertises rather
than a suspected one.