Skip to content

fix(studio): undoing an agent's build takes its sections off the timeline too - #4757

Open
miguel-heygen wants to merge 3 commits into
mainfrom
fix/studio-undo-drops-removed-sections
Open

miguel-heygen wants to merge 3 commits into
mainfrom
fix/studio-undo-drops-removed-sections

Conversation

@miguel-heygen

@miguel-heygen miguel-heygen commented Sep 30, 2026 •

Copy link
Copy Markdown
Collaborator

What

Undoing an agent's build of sections now takes those sections off the timeline too. Before this change, the file went back but the timeline kept showing every section the build added, until the project was reopened.

Why

When a shorter clip list arrives, mergeTimelineElementsPreservingDowngrades keeps each old element that has a compositionSrc. The rule exists for sub-composition children that a bare DOM re-scan drops and enrichMissingCompositions re-adds. A section the agent built is also a sub-composition host with a compositionSrc. So after an undo, the runtime reported the reverted film's clips (3), and the merge added the removed sections back (6).

To reproduce on main: have an agent add sections hosted by data-composition-src, then press Cmd+Z. The file and the picture go back, but the timeline keeps the sections. In the run below this happened in 5 of 7 runs. The other runs got a longer list first, which the merge trusts in full.

How

  • mergeTimelineElementsPreservingDowngrades takes an inPreview check. An old element is kept only while its node is still in the preview.
  • syncTimelineElements, the one place every discovery path writes through, passes findTimelineElementInIframe. That is the composition-aware lookup the other timeline edits use.
  • A sub-composition child that a re-scan drops is still in the preview, so it is still kept.
  • Sections that enrichMissingCompositions adds (buildMissingCompositionEntry) are now kind: "composition", as parseTimelineFromDOM names the same node. Without it the lookup searched index.html for a host that belongs to its own composition and never found it, so each report would drop and re-add those rows. This also lets the lookup's other callers find these rows.
  • On a background (shadow) reload, iframeRef points at the new document before its clip list is committed. Before, the commit read the old document, which still held the undone sections.

Test plan

  • Unit tests added/updated
  • Manual testing performed
  • Documentation updated (if applicable)
  • Comments follow CONTRIBUTING.md "Comments"

What I measured

On a Linux box:

  • Three new tests, each failing without its own fix:
    • timelineDOM.test.ts: a section whose host left the preview is dropped;
    • timelineIframeHelpers.test.ts: an enriched host is a composition the lookup finds in its preview;
    • useTimelinePlayer.shadowReload.test.ts: after a shadow reload, a section the new document no longer has leaves the timeline, though the old document still holds it. It fails with main's merge rule, and with the old commit order.
  • The nearby test files (timelineDOM, useTimelinePlayer, its shadowReload tests, useTimelineSyncCallbacks, timelineIframeHelpers, previewMessageRouter): 141 of 141 pass.
  • Typecheck, lint, format and the fallow audit are clean.
  • An end-to-end run in a host app: an agent stand-in adds three sections, then Cmd+Z. On 0.8.94 the timeline kept 6 clips while the file had 3, in 5 of 7 valid runs. With this build (this head) it showed 3 of 3 in 5 of 5 runs.

What I did NOT exercise

  • No run on macOS or Windows.
  • The Studio app itself, outside a host app.
  • Undo of a build of inline (not data-composition-src) compositions.

Before

After Cmd+Z the run card reads Undone and the file holds only Title, Subtitle and Tag, but the timeline still shows Intro Hook, Benefit Fresh and Closing Cta.

Before: after Cmd+Z the timeline still shows the three built sections

After

After the same Cmd+Z the timeline shows Title, Subtitle and Tag, like the file.

After: after Cmd+Z the timeline matches the file

@miguel-heygen
miguel-heygen force-pushed the fix/studio-undo-drops-removed-sections branch from 1a74885 to 46eced4 Compare September 30, 2026 08:41
@miguel-heygen
miguel-heygen marked this pull request as ready for review September 30, 2026 09:18

This branch has not been deployed

No deployments
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