Updated activitypub Bluesky sharing enablement flow#20
Conversation
ref TryGhost/ActivityPub#1377 We updated the backend implementation of the Bluesky sharing enablement process to include a confirmation step in which the client would prompt the backend to check what handle has been assigned to the Bluesky account generated by Bridgy Fed - This circumvents the need to for us to compute the handle manually and potentially getting it wrong if we compute it in a different way to Bridgy Fed
🤖 Augment PR SummarySummary: Updates the Bluesky sharing enablement flow to use the ActivityPub v2 endpoints and a two-step “enable → confirm handle” activation process. Changes:
Technical Notes: The UI polls confirmation every 5s (up to 12 retries) and falls back to disabling if confirmation does not complete. 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| } finally { | ||
| setLoading(false); | ||
| } | ||
| await enableBlueskyMutation.mutateAsync(); |
There was a problem hiding this comment.
If enableBlueskyMutation.mutateAsync() rejects, loading stays true because there’s no finally/error path resetting it; that can leave the UI disabled until refresh. Consider ensuring setLoading(false) happens on failure as well.
🤖 Was this useful? React with 👍 or 👎
| }; | ||
|
|
||
| const confirmHandle = useCallback(() => { | ||
| confirmBlueskyHandleMutation.mutateAsync().then((handle) => { |
There was a problem hiding this comment.
This mutateAsync().then(...) chain doesn’t handle rejections; on network/API errors it can become an unhandled promise rejection in the browser. Consider awaiting with try/catch or adding a .catch(...) so polling errors are handled gracefully.
🤖 Was this useful? React with 👍 or 👎
|
|
||
| toast.error('Something went wrong, please try again.'); | ||
|
|
||
| await disableBlueskyMutation.mutateAsync(); |
There was a problem hiding this comment.
If disableBlueskyMutation.mutateAsync() throws here, the interval callback will reject and setLoading(false) won’t run, potentially leaving the UI stuck in loading. Consider guarding this with error handling in the failure path.
🤖 Was this useful? React with 👍 or 👎
| } | ||
|
|
||
| retryCountRef.current += 1; | ||
| confirmHandle(); |
There was a problem hiding this comment.
Because confirmHandle() triggers an async request but is called from a fixed setInterval, a slow request can overlap with the next tick and fire multiple concurrent confirmations. That can inflate retry counts and increase chances of 429/rate-limit errors.
🤖 Was this useful? React with 👍 or 👎
3 participants
Benchmark PR from qodo-benchmark#244