Skip to content

The upgrade marker outlives its snapshot and warns forever #143

Closed

Description

@dipto0321

Problem

nodeup upgrade writes an upgrade marker (<DataDir>/upgrade-in-progress.json) so that an interrupted migration can be detected and replayed. The marker deliberately survives a failed restore — that is the contract that lets the user replay their global npm packages.

But the marker points at a snapshot, and the snapshot does not necessarily survive:

When that happened, the marker outlived its payload and every nodeup invocation printed a warning whose own recovery command was guaranteed to fail:

⚠ Detected an interrupted upgrade (snapshot: .../snapshots/fnm-26.10.0.json, started: 2026-10-22T10:28:49+06:00).
⚠ To resume: `nodeup packages restore --from .../snapshots/fnm-26.10.0.json`
• No snapshot files found.

The marker lives outside the snapshots/ directory, so nodeup packages cleanup never touched it — the user had no way to dismiss the warning.

Expected behavior

  • A marker whose snapshot is still on disk is a genuine interrupted upgrade: keep warning, keep the resume hint, keep the marker armed.
  • A marker whose snapshot is gone is stale: clear it, and say so once instead of printing a hint that cannot work.
  • Clearing must be race-safe: a concurrent nodeup upgrade that arms a fresh marker must never have it deleted.
  • The user should also have a manual escape hatch: nodeup packages cleanup --stale-sentinel.

Acceptance criteria

  • warnInterruptedUpgrade validates its own advice before printing a resume hint
  • A stale marker is cleared automatically and reported
  • A live marker is never cleared (the bug(packages): restore aborts on first failed install; migration report never written #46 contract)
  • Clearing is atomic against a concurrently-armed marker
  • nodeup packages cleanup --stale-sentinel clears only stale markers
  • Regression tests for the stale case, the live case, and the race
  • The CLI test suite is hermetic — no test may touch the developer's real $HOME state

Activity

  1. dipto0321 commented on Nov 2, 2026

    @dipto0321
    OwnerAuthor

    Duplicate of #141, which was fixed by PR #142 and released in v1.2.4. Closing this rather than tracking the same bug twice.

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

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions