Sync developer-approval and transfer-accept calls with api's v2 hardening - #286
Merged
Conversation
… v2 review workflow
The api repo's "Harden extensions v2 review workflows" change added
optimistic-concurrency protection to developer approval and moved
transfer acceptance off a path param, both breaking this site's client:
- POST /developers/{id}/approve now requires an expected_revision body
matching the profile's content_revision, so an approval can't silently
apply to a profile edited after it was reviewed.
- Accepting a transfer moved from POST /developers/transfers/{token}/accept
to POST /developers/transfers/accept with token in the JSON body.
Claude-Session: https://claude.ai/code/session_01TqhETgC1HU7JBgSbsiWAh1
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
extensions | 9359dfd | Commit Preview URL Branch Preview URL |
Jul 26 2026, 11:49 PM |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
getDeveloperByOwner is typed to return DeveloperProfile, which now requires content_revision: number, but its D1 query never selected the column — parseDeveloperProfileRow's `as DeveloperProfile` cast papered over the gap, so the field would silently be undefined at runtime for any owner-read profile. Select the column (added to `developers` by the api repo's 0011 migration, NOT NULL DEFAULT 1) so the value is real. getDeveloperById's public read still doesn't select it, since its PublicDeveloperProfile return type omits the field entirely. Claude-Session: https://claude.ai/code/session_01TqhETgC1HU7JBgSbsiWAh1
There was a problem hiding this comment.
0 issues found across 1 file (changes from recent commits).
Auto-approved: Syncs API client with backend's optimism-concurrency guard and endpoint change; bounded adaptation to already-deployed API hardening.
Re-trigger cubic
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.
Summary
fossbilling/apirepo's "Harden extensions v2 review workflows" change madePOST /developers/{id}/approverequire anexpected_revisionbody (matching the profile'scontent_revision) as an optimistic-concurrency guard, and moved transfer acceptance fromPOST /developers/transfers/{token}/accepttoPOST /developers/transfers/acceptwithtokenin the JSON body — both were silent breaks for this site's API client.apiClient.ts(approveDeveloper,acceptTransfer), addedcontent_revisionto theDeveloperProfiletype (and excluded it fromDeveloperProfileInput/PublicDeveloperProfile), and threadedexpected_revisionthrough the developer-approval form and route handler.DELETE /developers/me, new public read endpoints, submission-list pagination) were checked and need no changes here — the delete endpoint was already wired up, the public read endpoints aren't used since this site reads D1 directly, and pagination is additive.