Skip to content

Blocks provenance: three lifecycle nits, unreachable today #108

Open

Description

@ryandmonk

Maintenance record for three non-blocking nits that the independent review of #107 found in the experimental provenance lifecycle. The owner accepted them and chose not to fix them in that merge. Each is unreachable through the UI today; this issue records the precondition that would make each one reachable. Line references are at main cb50f84. All of this code is in the experimental build only; the default build carries none of it.

A. Session-store timing (predates #107)

What. An Example session keeps its provenance in one shared ref, sessionProvenance. openExample and closeProject reset that ref (apps/composer/app/state.tsx:562, :717). Writes to the session store run on a serialized chain keyed "session" (apps/composer/experimental/blocks-runtime.ts:454, :460):

  • the accept's recordProvenance (state.tsx:1546);
  • a save's gcProvenance (state.tsx:874);
  • the duplicate's copyProvenance (state.tsx:597).

A write still queued when the ref is reset lands afterwards, in the next session's map. A copy whose turn comes after a reset reads the reset map.

Precondition that would make it reachable. Opening or closing an Example within milliseconds of an accept, save or duplicate in the previous session, before that write's chain has run. Through the UI this needs a navigation plus a click inside one chain turn (a dynamic-import resolution and a sha256), so it is not reachable today. It becomes reachable if the session-store writes get slow, for example if they start awaiting network or heavy work.

Effect if reached. Labels stay truthful, because a label needs exact expansion identity and the project's own reference. A stray record in the next session shows at worst an inert line. A duplicate never carries one, because the copy prunes against the kept examples.

Fix when needed. Give each Example session its own holder, or its own store key, instead of resetting one shared ref.

B. copyProvenance deadlocks when source and target share a key

What. copyProvenance(from, to, examples) runs on from.key's chain and awaits a nested serialized(to.key, …) (blocks-runtime.ts:525, :529). If from.key === to.key, the inner write waits behind the outer one, which never finishes.

Precondition that would make it reachable. A caller copying a store onto itself, or onto another store with the same key. Its only caller, duplicateExample (state.tsx:597), copies the "session" store into a newly created project's store, whose key is a generated project id.

Fix when needed. A one-line guard: return early, or save in place, when from.key === to.key.

C. copyProvenance overwrites the target instead of merging into it

What. The copy saves the pruned source map as the target's whole map (blocks-runtime.ts:529), replacing anything the target already held.

Precondition that would make it reachable. Copying into a project that already has provenance. The only caller copies into a project created moments earlier, which has none.

Fix when needed. Merge into the target's current map, under the target's chain, if a caller ever copies into an existing project.

Activity

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