Skip to content

deltic-setup: fail loud when .deps checkouts are stale against setup.sh's pins #64

Description

@lannbot

The stale-.deps trap has now fired three times (the #51 mis-diagnosis, and twice on 2026-08-12 during #59 and #63 work): a sibling-pin bump lands on main, existing worktrees keep their old .deps checkouts, and the next just exam-deltic fails deep inside deltic-setup with a deno lockfile diff — a message whose real meaning is "re-run scripts/setup.sh", but which reads like registry or sibling motion and has twice invited wrong diagnoses.

The fix is a cheap guard at the front of deltic-setup (or a shared deps-check recipe the other .deps consumers — relay-build, build-hosts — could also use): compare each .deps/<name> checkout's git rev-parse HEAD against the pin in scripts/setup.sh, and fail with the honest instruction when they diverge:

.deps/webcrypto is at 8a3de9c but scripts/setup.sh pins a0c924d — run ./scripts/setup.sh

Notes:

  • The iroh pin is a tag object id, not a commit id (816dd70c… resolves to commit f2eb930d…), so the comparison needs rev-parse <pin>^{commit} against rev-parse HEAD rather than string equality — the same wart that makes setup.sh's own idempotence check re-checkout iroh every run.
  • CI is immune (fresh checkout + setup every run); this is purely a developer/worktree ergonomics guard, but the failure it replaces is expensive precisely because it looks like an upstream incident.

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