Environment
- Adobe Premiere Pro 26.3.2 (Build 2) — shipping release (not Beta)
- Built against
@adobe/premierepro26.5.0-beta.61(type definitions only; runtime API from the host) - UXP manifest v5 · Windows 11
Summary
Several UXP Premiere APIs return true / resolve their Promise before the operation has actually been applied or validated — so the success result doesn’t reflect reality. This spans sequence editing, project import, and transaction actions, and shows up across multiple versions from 25.3 Beta through the current shipping 26.3.2. The practical effect: developers cannot trust any success boolean from this surface and must independently read state back to know what happened. Filing these together because they look like one underlying contract/timing defect rather than four unrelated bugs.
(New-user 2-link limit — only two threads are linked below; the rest are cited by thread number, searchable on this forum.)
History / severity (not brand-new, but seemingly worse lately)
These behaviors are not new to my plugin. The codebase already carried explicit workarounds for two of them well before this report: a post-changeMediaFilePath re-assert of the sequence In/Out points (Instance 1), and deliberate avoidance of TrackItemSelection.createEmptySelection() because it reproducibly raises “The script object is no longer valid” (Instance 4). Instance 1 also has an older report on 25.3 Beta (thread 10765, linked below).
What changed recently for me: those one-shot mitigations, which sufficed through months of reliable runs, stopped being enough on current Premiere versions. The In/Out setpoints now routinely need several verify-and-re-assert passes before they hold, and the script-object error began hard-failing entire operations that previously slipped through. So, this is best read as a longstanding timing/validation weakness whose frequency and severity increased on recent Premiere builds for whatever reason (same unchanged plugin logic).
Instance 1 — createSetInPointAction / createSetOutPointAction reports success but doesn’t apply
Inside executeTransaction, these return success=true, but the sequence In/Out points don’t change. Previously reported on 25.3 Beta in thread 10765 (now closed); still reproduces in shipping 26.3.2.
set in point to 0 → executeTransaction success=true
getInPoint() → 6.339s // expected 0
Most reproducible right after a ClipProjectItem.changeMediaFilePath() on a still-image clip earlier in the sequence: swap a still at [0s, 6.34s] → set In to 0 (reports success) → In reads back as 6.34s (the still’s out-boundary). Intermittent — consistent with the set racing Premiere’s internal re-evaluation of the swapped still and resolving before it settles. Reliable workaround: set → read back via getInPoint/getOutPoint → re-assert in a loop until it holds.
const end = await seq.getEndTime();
for (let i = 0; i < 6; i++) {
await project.lockedAccess(() => project.executeTransaction((ca) => {
ca.addAction(seq.createSetInPointAction(ppro.TickTime.TIME_ZERO));
ca.addAction(seq.createSetOutPointAction(end));
}, "set in/out"));
await new Promise(r => setTimeout(r, 250));
if ((await seq.getInPoint()).seconds <= 0.02 &&
Math.abs((await seq.getOutPoint()).seconds - end.seconds) <= 0.02) break;
}
Instance 2 — Project.importFiles([...]) returns true for a path that doesn’t exist
Should return false. (thread 12354)
const success = await proj.importFiles([""]);
console.log({ success }); // { success: true } — expected false
(An Adobe reply in 2017 noted true here only ever meant “no internal error raised,” with import failures surfaced via a dialog — i.e. the boolean has never actually meant “imported.” Worth revisiting as a documented contract.)
Instance 3 — importAEComps / importAllAEComps return true but import nothing
Returns true immediately; no compositions land in the Project panel (the same .aep drag-drops in fine manually). Reported on v26.2.2. (forum thread 11966 — “importAEComps returning true but silently failing to import compositions in Premiere”)
Instance 4 — create*Action intermittently throws "The script object is no longer valid."
On freshly re-fetched objects, mid-transaction, across several different actions — consistent with the call racing internal background work rather than being settled when control returns (forum threads, by number):
- createKeyframe / createSetValueAction — thread 11999
- createMoveItemAction — thread 11935
- appending a video filter component — thread 11984
Suspected shared root cause
These calls return/resolve before the host has applied or validated the operation — so they report success prematurely and race internal background work; the In/Out call additionally mutates the sequence’s In/Out points as a side effect of a later re-evaluation.
Requested fixes:
- Don’t resolve a Promise / return
trueuntil the operation is actually applied. - Return
false(or reject the Promise with anErrorallowing atry/catchor.catch) when the operation did not happen — e.g. bad/empty/non-existent path, nothing imported, no state change — not an untruetrue. - Don’t mutate unrelated sequence state (e.g. In/Out points) as a side-effect of media re-evaluation.
- Until then, please document that these
successvalues are unreliable and must be verified by reading state back.
Repro: happy to provide a minimal plugin for any single instance.