Skip to content

Don't delete a speaker's recording when its reused b-roll copy is moved into a slot [#1131]#1346

Open
kinjitakabe wants to merge 1 commit into
e35dev:mainfrom
kinjitakabe:fix/layout-first-broll-move-preserves-speaker
Open

Don't delete a speaker's recording when its reused b-roll copy is moved into a slot [#1131]#1346
kinjitakabe wants to merge 1 commit into
e35dev:mainfrom
kinjitakabe:fix/layout-first-broll-move-preserves-speaker

Conversation

@kinjitakabe

Copy link
Copy Markdown

Summary

On the layout-first placement canvas, a recording can deliberately live in a speaker slot and the optional b-roll slot at the same time — reusing a host/guest take as a cutaway is a normal production choice, not a duplicate (the invariant added in #1304). But moving that reused b-roll copy into another speaker slot silently deleted the separate speaker placement it was reused from.

Reproduce (interview layout): place host-take.mp4 in Host, a guest take in Guest, reuse host-take.mp4 as the b-roll cutaway, remove the Guest video, then drag — or focus and arrow-key — the b-roll copy into the now-empty Guest slot. Before this change the Host slot is silently emptied: the host's recording is gone with no warning. The keyboard arrow-move path goes through the same code, so it loses the recording too.

Cause: moveSlotVideoplaceVideoFileclearMatchingSource enforces "one recording per speaker slot" by clearing any other speaker slot holding the same recording. On a move out of the b-roll slot the target is a speaker slot, so the existing b-roll exemption doesn't apply and the Host slot — which legitimately shares the recording under the #1304 reuse rule — is cleared. A move/swap should only rearrange the two slots it involves; it must never net-destroy a third slot's placement.

Change

  • moveSlotVideo now marks a move out of the b-roll slot so the placement skips the speaker-slot matching-source cleanup (skipMatchingClear when the move origin is b-roll). The reused b-roll copy is relocated without deleting the speaker slot it was reused from.
  • placeVideoFile honors that option; every normal drop/click/file-input placement is unchanged and still enforces one recording per speaker slot.
  • Net result of the move: the b-roll source is vacated, the recording lands in the target slot, and the host placement is preserved. The two speaker slots now sharing the recording are surfaced by the existing duplicate guard (and gate Continue) for the creator to resolve — an honest, recoverable state instead of silent data loss.

Verification

  • New regression test preview/layout-first-broll-move-preserve.test.js reproduces the data loss against the old code and locks in the fix: host preserved, b-roll vacated, recording moved, and the now-shared recording reported as a duplicate. It also guards the scope with a plain (non-b-roll) move that still relocates cleanly.
  • node scripts/run-tests.mjs — all 105 smoke test files pass; the existing b-roll reuse and move/swap suites stay green.
  • git diff --check is clean. Static, dependency-free change to the existing preview/layout-first.js placement logic; no new surface.

Extends the #1304 reuse invariant on the #1131 layout-first video-placement path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant