4grayandClaude Opus 5 ed442da3ca fix(portals): re-check the movie after waiting, and follow the alternative ...

Three findings, two of them regressions from the previous round.

Awaiting a pending discovery before failover let the user navigate during
that wait: the continuation then ran against whatever controller was current
and could answer one film's playback failure by starting another film's
alternative. Both waits — failover and pinned Play — now re-check that the
same movie still owns the screen.

Pinned Play also needed the wait it did not have. Pressing Play while the
pin lookup was still out concluded "nothing is pinned" and started the
route's own source, making a persisted preference depend on worker latency.

And the position bridge still accepted only the route's ids, so an external
player running an alternative had every progress update discarded: the
resume point stayed where playback began and a switch an hour in rewound the
lot. The session matcher and the bridge now share one ownership predicate,
since a page that shows Stop for a session whose progress it throws away is
the bug in two halves.

The test for the external case previously set the position signal directly,
which bypassed the very filter that was broken; it now drives the bridge.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-28 01:52:43 +02:00

..

architecture

fix(portals): re-check the movie after waiting, and follow the alternative

2026-07-28 01:52:43 +02:00

superpowers

feat(mock-data): add shared screenshot-safe poster catalog (#1271)

2026-07-27 08:10:57 +02:00