Skip to content

seal store: two specs derive one seal file name, and seal --save overwrites the other spec's seal #8540

Open

Description

@gHashTag

seal_file_path(module, path) names a seal <parent dir>_<module>.json. Two specs in directories with the same name and the same module name derive the same file. t27c seal --save on one of them then overwrites the other spec's seal, without a warning.

Found by the first full t27c frontier --reseal run on master (2026-10-10, #8392), on 5 files:

seal file owner overwritten by
openxc7-synth_trinity_top.json port/trinity/fpga/openxc7-synth/multi_led_test.t27 .../trinity_top.t27
scripts_port-scripts.json port/scripts/gen_w390.t27 port/scripts/gen_w391.t27
src_lib.json port/trios/.../trios-store/rings/ST-00/src/lib.t27 .../trios-scarab-types/rings/SR-03/src/lib.t27
tri_port::trinity::src::tri.json port/trinity/src/tri/gen_varint.t27 .../gen_transaction.t27
coder_igla-coder-pipeline.json igla/coder/pipeline.t27 another spec with module igla-coder-pipeline

--reseal now refuses to keep or delete such a file (remint_keeps(..., file_is_its_own)), but seal --save itself still overwrites it. Most of these are bee ports that share a module name such as port::scripts.

Acceptance criteria

  • t27c seal --save refuses to write a seal file whose recorded spec_path is another spec, and names both specs.
  • The colliding specs get distinct module names, or a naming rule that cannot collide, and each keeps its own seal.
  • A test plants two specs that derive one name and shows the second save is refused.

Boundary

bootstrap/src/main.rs
.trinity/seals/

User Scenarios

  • Given two specs in different directories with the same parent directory name and same module name, when the first spec runs t27c seal --save and then the second spec runs t27c seal --save, then the second save is refused with an error naming both specs and the first spec's seal remains intact.

  • Given a spec runs t27c seal --save targeting a seal file whose recorded spec_path belongs to a different spec, then the command exits with a non-zero code and prints a collision message identifying both the current spec and the recorded owner spec.

Requirements

FR-001: t27c seal --save MUST read the existing seal file's spec_path before writing and refuse to overwrite when it differs from the current spec's path.

FR-002: The refusal error MUST name both the current spec path and the recorded owner spec path.

FR-003: The seal file naming rule MUST be changed so that specs with the same module name in same-named parent directories produce distinct seal file names, or module names MUST be made unique across colliding specs.

FR-004: A test MUST exist that creates two specs deriving the same seal file name, saves the first, attempts to save the second, and verifies the second save is refused.

Activity

  1. gHashTag commented on Oct 10, 2026

    @gHashTag
    OwnerAuthor

    Two more collisions, found while resealing for #8641: openxc7-synth_trinity_top.json and tri_port::trinity::src::tri.json were overwritten by seal --save of another spec with the same derived name, and were restored from master. Every bulk reseal has to diff spec_path against master until this is fixed.

  2. added a commit that references this issue on Oct 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions