stacklok / stacklok/mecatl

session: make checkpoint persistence failures observable and policy-driven

Open
#470 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
152
Forks
16
Avg merge
14h 48m
Merged PRs (30d)
536

Description

Problem

Main-loop and delegated-session checkpoints are best effort: save errors are discarded. A run can report success while its latest main, Subagent, Parallel, or Team snapshot was not persisted, leaving resume/inspection stale without telling the operator.

Desired outcome

Give persistence failures an explicit, bounded, operator-visible policy without turning transient storage failures into duplicate model/tool execution.

Scope

  • Inventory every checkpoint site and classify which saves are required vs best effort.
  • Define retry/backoff and terminal behavior for failures before a run, at turn boundaries, while awaiting approval, and at child termination.
  • Surface failures through the existing diagnostics/event taxonomy without leaking transcript content or adding noisy duplicate lines.
  • Preserve cancellation-detached terminal child saves and bounded shutdown.
  • Add tests proving a reported successful durable outcome cannot silently depend on a failed required checkpoint.
  • Document degraded behavior for stores that become unavailable mid-run.

Acceptance criteria

  • Save failures are never silently discarded.
  • The policy avoids replaying an already-started model stream or tool call.
  • Main and delegated sessions follow one documented classification of required/best-effort checkpoints.
  • Operators can identify the affected session ID and checkpoint without exposing prompts/tool arguments.
  • Offline failure-injection tests cover main, foreground child, background child, Parallel, and Team paths.

Relevant code

  • engine/agent/loop.go
  • engine/agent/subagent.go
  • engine/agent/parallel.go
  • engine/agent/teamsupervisor.go
  • internal/adapter/server/service.go

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing checkpoint sites in engine/agent/loop.go, subagent.go, parallel.go, teamsupervisor.go, and internal/adapter/server/service.go, then inventory their required or best-effort behavior. Define the bounded failure policy and diagnostics flow without replaying started work; done means failure-injection coverage for main, child, Parallel, and Team paths plus documented degraded behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.