"The script object is no longer valid" thrown randomly by createKeyframe/createSetValueAction during background activity — async reads unaffected

Premiere Pro
,
1

I’ve been debugging intermittent Error: The script object is no longer valid. in a UXP panel and have instrumentation data that narrows down the failure mode considerably. This appears related to this thread, where the root cause was left unresolved.

Environment: Premiere Pro [VERSION], UXP manifest v[N], macOS [VERSION]

Setup: The panel sets Motion params (Position/Scale/Crop) on selected clips. All the documented rules are followed: all async work (getComponentChain, getParam, getStartValue) is resolved before locking; lockedAccess and executeTransaction callbacks are fully synchronous; keyframes and actions are created inside lockedAccess; all API work is serialized (one operation at a time, never overlapping) with settle delays between operations.

Observed behavior:

  1. Operations work reliably for a while (10+ consecutive operations), then the panel enters a “storm” window lasting minutes, during which synchronous createKeyframe() and createSetValueAction() calls inside lockedAccess fail with “script object no longer valid” — randomly and independently per call. Per-call instrumentation shows the failing call position varies between attempts (position, scale, cropBottom, etc., no pattern).
  2. During the same window, async reads on the same objects succeed — getStartValue(), getComponentChain(), getParamCount(), getTrackIndex() all work fine. Only synchronous action/keyframe creation fails.
  3. The failure probability appears per-call: an operation making 2 create calls succeeds intermittently during the storm, while an operation making 12 create calls essentially never completes. Falling back to one param per transaction with retries succeeds where a 12-action compound transaction cannot.
  4. Re-fetching everything from scratch (fresh getActiveProject() → sequence → selection → trackItems re-resolved directly from track.getTrackItems() → fresh component chain walk → fresh params) does not help while the window lasts. The objects are fresh; the create calls still fail.
  5. Timing correlation: the storm tends to begin after repeated transactions on stacked multicam clips (with program monitor rendering ongoing), suggesting the create calls race against internal background work rather than actual object invalidation.

Question: Is there any way for a panel to detect or wait out this state — e.g., an API to query whether the host can currently service synchronous action creation, or a guaranteed-stable window? Retrying per-param with backoff works but produces multiple undo steps and is clearly a workaround for a host-side race.

Happy to provide the full instrumented logs or a reduction if useful.