Skip to content

Freeze: preserve cross-restart resume for concurrent trials (Option B follow-up to #10) #11

Description

@kentwelcome

Context

PR #10 fixed the freeze-repo HEAD-lock race that blocked concurrency.trials > 1 by giving each concurrent cell its own freeze git repo: resolve_freeze_dir() now returns <cas-root>/<sealed_hash>/<cell_token>, where cell_token derives from the harbor trial name.

This deliberately drops the sealed_hash-only shared-CAS property: a cell that Harbor resumes under a regenerated trial name (new random suffix) resolves to a different freeze tree, so it starts fresh instead of recovering the prior workspace checkpoint. The old tree is left orphaned.

An adversarial Codex review independently flagged this as a [high] finding. It is correct but intentional — see the trade-off documented in PR #10 and docs/razorback-implementation/_artifacts/FREEZE_REPO_RACE_HANDOFF.md.

Why it was deferred

Both properties (per-attempt isolation + resume-by-stable-identity) cannot be satisfied with what Harbor exposes today: generate_trial_name() = {task_prefix}__{ShortUUID(7)}. The task_prefix is stable across resume but shared by concurrent attempts; the random suffix isolates attempts but regenerates on resume. There is no stable per-attempt index.

Practical impact is limited because the solver re-invokes the agent on resume regardless (the resume branch only runs git checkout -- .; it is not a memoization that skips agent execution). So the regression is "lost workspace-checkpoint recovery for interrupted long-running cells," not "lost idempotency / duplicate grading."

What Option B would require

  • A stable per-(task, attempt) identity threaded from Harbor into the freeze key (needs a Harbor change, or a persisted trial_name -> freeze_dir mapping that rebinds a regenerated trial name to its existing tree), and
  • A regression that simulates Harbor deleting trials/<old> and re-running under a new trial name, proving setup() restores from the prior freeze instead of creating a fresh one.

When to prioritize

Raise priority if interrupted/resumed long-running cells become a real part of the workflow (i.e., the freeze checkpoint recovers expensive work). The workspace->freeze sync lives in the external spacedock plugin and was not audited here.

Refs: PR #10, src/razorback/agents/spacedock_solver.py (resolve_freeze_dir / _cell_token / _trial_name).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions