Two gaps in the CMS side of the Luminary Media Convert integration, both about what the editor is told when things do not go straight through.
An encode in flight is invisible after a reload
An encode runs for minutes inside an application the browser does not own. The session was held in component state and torn down on unmount, so a reload — or moving to another document and back — left the editor with no status, no progress, and a document the encoder was still writing to. They could not tell a running encode from a dead one.
The session handle is now stored per document and picked back up on arrival, reading the session's current state in one request before following its event stream.
The read token is watch-only by design — it cannot start, cancel, or reach the source file — so storing it grants nothing.
Notes on the approach:
- Re-attaching does not re-POST the session. That request is idempotent and would return the right session, but
notifyHost fires on the reuse path too, so the encoder window would jump to the foreground on every page load. Right for a click, wrong for a mount.
- The playback URL is written back on resume, not just followed: a reload before the first
encoding event would otherwise lose the destination the encoder is already publishing to.
- The stored handle is dropped only when the encoder answers that it no longer holds the session. An encoder that is merely closed must not cost the editor a session still running behind it.
A non-Chromium browser fails in a way that looks like the encoder's fault
Only Chromium implements the Local Network Access grant this depends on. Everywhere else the health check fails, and the CMS offered a luminary-convert:// launch link that can never work however many times it is clicked — the same treatment as an encoder that is simply switched off.
The browser is now consulted about a failure rather than before the request, so an encoder that answers is believed whatever the user agent claims, and a refusal that is the browser's doing says so. iOS browsers are excluded by name, being WebKit under a Chromium badge.
A 403 on the session now says to accept the prompt in the encoder window — by far its likeliest cause — while keeping the status code for support.
Scope
cms/ only. No API, shared or encoder changes.
Full CMS suite green: 127 files, 1078 tests (27 new). vue-tsc clean.
Two gaps in the CMS side of the Luminary Media Convert integration, both about what the editor is told when things do not go straight through.
An encode in flight is invisible after a reload
An encode runs for minutes inside an application the browser does not own. The session was held in component state and torn down on unmount, so a reload — or moving to another document and back — left the editor with no status, no progress, and a document the encoder was still writing to. They could not tell a running encode from a dead one.
The session handle is now stored per document and picked back up on arrival, reading the session's current state in one request before following its event stream.
The read token is watch-only by design — it cannot start, cancel, or reach the source file — so storing it grants nothing.
Notes on the approach:
notifyHostfires on the reuse path too, so the encoder window would jump to the foreground on every page load. Right for a click, wrong for a mount.encodingevent would otherwise lose the destination the encoder is already publishing to.A non-Chromium browser fails in a way that looks like the encoder's fault
Only Chromium implements the Local Network Access grant this depends on. Everywhere else the health check fails, and the CMS offered a
luminary-convert://launch link that can never work however many times it is clicked — the same treatment as an encoder that is simply switched off.The browser is now consulted about a failure rather than before the request, so an encoder that answers is believed whatever the user agent claims, and a refusal that is the browser's doing says so. iOS browsers are excluded by name, being WebKit under a Chromium badge.
A 403 on the session now says to accept the prompt in the encoder window — by far its likeliest cause — while keeping the status code for support.
Scope
cms/only. No API, shared or encoder changes.Full CMS suite green: 127 files, 1078 tests (27 new).
vue-tscclean.