fix(studio): surface save failures when deleting all animations for an element#1411
Conversation
…n element `deleteAllForSelector` fired its mutation with `void commitMutation(...)`, so a failed "Delete all animations for element" was swallowed: no error toast and no `trackGsapSaveFailure` telemetry, leaving the user believing it worked. Every sibling mutation in the hook (`deleteGsapAnimation`, `removeGsapProperty`, `removeAllKeyframes`, etc.) routes through `commitMutationSafely`, which catches the rejection and surfaces it. Route this one through the same wrapper. It is a single user action (one context-menu invocation per element), so the failure toast fires at most once, with no spam.
|
Closing — the function this PR claims to fix ( Happy to reopen if evidence of the issue is provided. |
|
Thanks for the careful look, and for the reopen offer. I think the review checkout may have been a bit behind #1366 —
|
Problem
deleteAllForSelectorinuseGsapScriptCommitsfired its mutation withvoid commitMutation(...):A failed "Delete all animations for element" was therefore swallowed — no error toast and no
trackGsapSaveFailuretelemetry — leaving the user believing the operation succeeded. Every sibling mutation in the hook (deleteGsapAnimation,removeGsapProperty,removeAllKeyframes,updateGsapProperty, …) routes throughcommitMutationSafely, which.catches the rejection, recordstrackGsapSaveFailure, and shows an error toast. This one handler was the only mutation that did not.Fix
Route
deleteAllForSelectorthroughcommitMutationSafely, matching its siblings. It is a single user action (one context-menu invocation per element), so the failure toast fires at most once — no spam.Notes
studio/srcfor the same fire-and-forget pattern: this was the only user-facing mutation that surfaced nothing. The remaining barecommitMutationcalls either return the promise for the caller to handle or have their own.catch(trackGsapSaveFailure).commitMutationSafelywrapper that ~10 sibling handlers rely on.