Skip to content

Tracking fws U8: interactive diff-view saves publish through the guard #2023

Closed

Description

@easonLiangWorldedtech

Retired in favour of #2427, "Tracking fws U8: diff-view save publishes through the guard". This tracker is retired and closed as completed; the work was not abandoned. #2427 is the issue PR #1916 closes today - measured at 2026-11-12T01:41:53Z at head 2a1b0a8 - and unit U8 of the file-write-safety split (epic #1375, chain tracked on #1991) is tracked there from now on. Everything below is kept as written; the successor carries the current state.

What this unit delivers: the interactive editor path - DiffViewProvider's save flows (saveChanges, saveDirectly) - publishes through the guard, with the teardown and cancellation ordering that keeps a rollback the last writer.

Why it matters: the diff view is the highest-traffic write path in the extension; a cancellation racing a publish must not leave the file half-applied or resurrect rolled-back content.

Implemented by: PR #1916 (branch fws/u8-diffview-guarded-save).

Acceptance:

  • saveChanges publishes through guardedWrite; a teardown that begins during the publish is honored after the publish settles.
  • revertChanges waits for an in-flight guarded publish before rolling back, so the rollback is provably the last writer.
  • open() serializes with a prior session's finalization.

Part of the file-write-safety epic #1375, landed as a nine-PR chain tracked on #1991. Merge order: U1 -> U2 -> U3 -> U4 -> U5 -> U8 -> U6 -> U7 -> U9.

Activity

  1. easonLiangWorldedtech commented on Nov 9, 2026

    @easonLiangWorldedtech
    ContributorAuthor

    Queue gate line for this tracker entry (#1916, da2b913).

    What the gate was: this entry could not be written until the row-level answers on #1912 and #1914 existed, because #1916's open rows are answered by deferral to the copy of the write queue that #1914 carries, and a deferral to an untriaged unit is not a disposition.

    The gate is cleared on my side: #1912's 19 asking rows were dispositioned at head 9d420ad in comment 6744486462 (created 2026-11-09T15:52:00Z per GitHub), and #1914's rows carry my earlier answers, whose latest review-comment entry from this account at the time of writing is id 4512376064 created 2026-11-09T11:48:16Z (REST /pulls/1914/comments, 2 pages read, 59 entries from this account; GitHub's Date header on that read: Mon, 09 Nov 2026 16:00:42 GMT). A further #1914 answer goes out today from this lane and will not undo this line.

    What still gates this queue position: both of #1916's asking rows (guardedWrite.spec.ts:804 and :970) want scenarios in src/core/tools/tests/guardedWrite.spec.ts, and that file exists as three distinct blobs - 32ab04c7c05459103ce8cd5bee8c736199a18964 at 7209a5f, 5ddc7544ce4c6ab8432afb2ac44a1a3b48d0bcee identically at a71761a and da2b913, 794c31836c45 at 1d993fb - with main tip e487cd7 carrying neither that file nor src/core/tools/guardedWrite.ts. The one place they are owed is #1914's copy, so this position waits on #1914's re-cut: it measures 1,044 counted executable lines at its merge base with main tip, above the 500-line cap, and it is third in the declared merge order 1910 then 1911 then 1914, so a commit on its current shape is not the answer. #1916's remaining ask, binding the edit publish at ApplyDiffTool.ts:256 to the version the read produced, is owed in #1916's own copy of that file (0de4b3a302905a1a0ae480e642f4cce2d5a5deda at da2b913, against 6e59d8c7ee2ee3669f69f04bb5ecee20275a7108 at #1915's head and b08ef9b6e629ce9c9752fc506b6eccaecf577d30 at main tip), because routing the diff-view save through the guard is that pull request's subject. Nothing was pushed and nothing is being asked of anyone by this comment.

  2. easonLiangWorldedtech commented on Nov 12, 2026

    @easonLiangWorldedtech
    ContributorAuthor

    This tracker is closed; here is where its content went, because completed does not say

    Written by lane u9-1917 at 2026-11-12T17:18:32Z. Posted on the campaign's instruction that the two retired trackers be closed with a state reason naming where the content went. The close itself was already executed: the timeline of this issue carries a closed event at 2026-11-12T02:12:06Z by easonLiangWorldedtech, and the issue object reports state closed with state_reason completed. The campaign did not patch this tracker's body, so the state reason the platform stores stays completed, and this comment is where the destination is stated in words.

    The content moved to #2427, the tracker the pull that carries the work actually closes. PR 1916 carries a closing link to #2427 and no closing link to #2023, which is the measured reason this campaign decided on 2026-11-12 that #2427 is the canonical tracker and this one is retired. The corresponding row on the campaign's tracking issue #1991 was rewritten from 19 bytes to 1,139 bytes in the body written at 2026-11-12T02:08:35Z to say the same thing.

    What was measured rather than asserted: the closed event and its actor came from this issue's own timeline, read on the anonymous door at 2026-11-12T17:18:32Z, and the pull's closing link came from the campaign's read of eight campaign pulls at 2026-11-12T01:41:53Z. What is absent and stays absent: the closed event carries a null state_reason, so the completed value a reader sees is the issue object's field and not the event's; and no code, verdict or merge order moved because of this close.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions