feat: auto-recover from LensAbortError on lens change#7
Open
msilivonik-sc wants to merge 2 commits into
Open
Conversation
useApplyLens silently short-circuited when sdkStatus was "error", leaving consumers wedged on the error view even when handed a new, playable lensId. useApplyLens now reinitializes the SDK when the lens intent (lensId + groupId + launch-data hash) changes while in a LensAbortError, then the existing apply effect applies the new lens once the SDK is ready. Gated to lens-abort only (bootstrap failures are unrelated to the requested lens) via the existing sdkError; emits an auto_reinit_on_lens_change metric. Always-on, no loop on a re-aborting lens. No public API changes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ttaallll
reviewed
Jun 5, 2026
| const prevRecoveryKeyRef = useRef(recoveryKey); | ||
| useEffect(() => { | ||
| const changed = prevRecoveryKeyRef.current !== recoveryKey; | ||
| prevRecoveryKeyRef.current = recoveryKey; |
Collaborator
There was a problem hiding this comment.
dont you need to move it to line 109?
ttaallll
approved these changes
Jun 5, 2026
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.
Summary
useApplyLenssilently short-circuits whensdkStatus === "error", leaving consumerswedged on the error view: handing
<LensPlayer>a new, playablelensIddid nothing,and the only escape was a manual
reinitialize(). This makes the library recover on its own.The bug
LensAbortError→ SDK is torn down,sdkStatus = "error".lensId(a different, possibly-fine lens).useApplyLenssees it but bails because the SDK is still in error.prevLensIdRef+reinitialize()workaround.Change
When the lens intent (
lensId+lensGroupId+ launch-data hash) changes while the SDKis in error and
sdkError?.name === "LensAbortError",useApplyLenscallsreinitialize(). Once the SDK returns toready, the existing apply effect applies thenew lens.
unrelated to the requested lens, so a lens change does not trigger a rebuild —
distinguished via the existing
sdkError, no new field.re-aborts under the same id won't churn. During reinit
sdkStatusgoeserror → initializing → ready, so existing loading UI covers the recovery.auto_reinit_on_lens_changemetric.No public API changes.
Testing
npm test→ 309 passed, incl. 7 new recovery tests (TDD, confirmed red before green).npm run typecheckclean.Follow-ups (out of scope)
prevLensIdRef/reinitializeworkaround once this ships.applyLenssetslensstate toreadyeven when its apply wassuperseded (resolved
false) — small targeted fix, tracked separately.