Add retention policy and garbage collection for ActorSnapshots

Problem

Every successful suspend creates an immutable ActorSnapshot, but superseded and deleted-Actor snapshots are never removed. An overnight soak produced 1,603 generations for one Actor, of which 1,602 were no longer referenced. Bucket lifecycle rules are unsafe because they cannot distinguish an old live snapshot from garbage.

Retention semantics

A snapshot is protected when any of these is true:

an Actor.latest_snapshot references it;
an ActorSnapshotTag references it;
it is among the newest minimumCount snapshots produced by its live source Actor UID; or
it is younger than minimumAgeSeconds and its source Actor still exists.

Add user-tunable policy to ActorTemplate.spec.snapshotsConfig:

retentionPolicy:
  minimumCount: 3
  minimumAgeSeconds: 86400

Both thresholds use OR semantics. minimumCount includes the Actor's latest snapshot. Explicit zero disables that threshold; omitted fields default to 3 and 86400. Policy updates apply to existing history on the next GC pass. Actor UID, rather than name, defines history so delete/recreate cannot inherit it.

Deleting an Actor removes count/age protection from its history immediately. Tags or references from other Actors still pin those snapshots.

Collection design

Run a periodic collector in ateapi. Use Kubernetes Lease leader election so only one replica collects at a time; the existing Redis distributed lock remains an alternative if Lease coordination proves unsuitable.
Determine retention from authoritative Actor, tag, snapshot, and ActorTemplate state. Before deletion, prevent new references and recheck roots so tagging/cloning cannot race GC.
Delegate deletion of the exact private snapshot prefix to any healthy atelet; atelet already owns the GCS/S3 clients and credentials. Add an internal idempotent delete-prefix RPC and backend implementations.
Delete object-storage bytes first, then snapshot metadata. On any failure, retain metadata and retry on a later pass. Never delete metadata first, which would make leaked bytes undiscoverable.
Keep GC interval/concurrency as operator settings; retention remains workload policy.
Emit basic attempted/deleted/failed counters and structured failure logs.

Out of scope

Partial failed uploads with no ActorSnapshot metadata (#610).
Node-local Actor directories and pause snapshots (#641).
Per-Atespace policies or storage quotas.
Manual DeleteActorSnapshot API.

Acceptance criteria

CRD defaults retain the newest 3 snapshots and all snapshots younger than 24 hours for each live Actor.
Users can tune either threshold, including setting either or both to zero.
Latest-snapshot and tag references are never collected.
Deleting an Actor makes its otherwise-unreferenced history collectable.
Concurrent tag/clone operations cannot produce a reference to deleted data.
GCS and S3-compatible prefixes are deleted idempotently; metadata is removed only afterward.
Kubernetes Lease leader election makes collection safe with multiple ateapi replicas, and collection resumes after process/storage failures.
Unit tests cover policy boundaries, references, races, and retry ordering; E2E verifies superseded and deleted-Actor cleanup while tagged snapshots survive.

Follow-up to #529, #568, and #570.

A few thoughts.

Snapshots and tags are similar to git commits, tags, and heads. What can we learn from git's GC policies? Those are pretty well tested.

Think of actors as git heads. Each actor is a branch. It has a "current" commit (snapshot). Each commit (snapshot) has a parent commit (snapshot), but git doesn't have to retain all of the history (--depth=N).

Our problem is a little different - git considers the commit parentage to be protected, and we are specifically saying we want to GC those. So it's more like a "floating" depth.

Git's rules:

Never delete a commit (snapshot) that is referenced by either a tag (tag) or head (actor). Only GC "unreachable" commits (snapshots).
Unreachable commits younger than $RETENTION_TIME are protected.

That's it (as far as I can tell). If you add in the depth rule it is:

Commits farther than $RETENTION_DEPTH from the head of any actor are eligible for GC.

Can we think really hard about the policies we need to express?

  minimumCount: 3
  minimumAgeSeconds: 86400

I think minimumCount == RETENTION_DEPTH in my notes?

I do not understand minimumAgeSeconds? Is it meant to be RETENTION_TIME? The word "minimum" doesn't express that to me.

Do tags count against minimumCount? That seems wrong. I see the need for a max N, but I think I would express it as:

Snapshots pointed to by Actors are "hard-protected"
Snapshots pointed to by Tags are "hard-protected"
Snapshots closer than $RETENTION_DEPTH from the head of any actor are considered "soft-protected"
Snapshots younger than $RETENTION_TIME from head of any actor are considered "soft-protected"
All other snapshots are considered "unreachable"

Prune all unreachable snapshots.
If the number of snapshots exceeds $RETENTION_MAX, prune soft-protected snapshots (oldest-first) until fixed

Thoughts?

A failure case the design doesn't cover: a partial listing during collection

Retention here is proved by absence — a snapshot is collectable because no tag references it, and because its source Actor is gone or superseded. So anything the collector fails to read is indistinguishable from something that doesn't exist:

A tag listing that returns partially → the unread tags' snapshots classify as unreachable → collected.
An Actor the collector failed to read looks exactly like a deleted Actor — and deletion is what unlocks collecting its whole history.

The design covers deletion failures (retain metadata, retry) and reference races (recheck before delete), but both assume the listings came back complete.

Where we hit this

Same shape in the image-cache GC (#463 Phase 2), found during code review of the eviction engine: an unreadable image record contributed no refcounts, so the layers it referenced looked unreferenced — one corrupt file converting into deletion of other, healthy data.

Why we fixed it by gating the whole pass (not skipping the unreadable item)

The two failure sides aren't symmetric:

A failed deletion → skip the item, retry next pass. Fine.
Failed evidence → acting on a partial protection set isn't less work, it's wrong work.

Mechanically: any scan that can't complete returns a sentinel (ErrIncompleteEnumeration), the pass deletes nothing, logs once naming the unreadable path, and retries next pass.

Does it apply here?

Depends on one property: are the store's listings all-or-nothing?

If a multi-shard scan can surface partial results rather than a hard error → worth one acceptance criterion ("a pass that cannot completely enumerate Actors, tags, and snapshots collects nothing and retries") and one unit test (a listing that errors mid-pass deletes nothing).
If listings are atomic → non-issue, but worth stating either way.

I have started looking into the snapshot cleanup. I want to confirm some assumptions before proceeding.
A) Are we onboard on building up on ActorSnapshot resource?
B) Assuming the snapshot information is stored in both Postgres DB and remote storage (S3/GCS) and thus would have to be cleaned up from these places (excludes local storage cleanup)
C) Right now we want to focus on the snapshot storage cleanup and the signed URL access would be implemented in a later release.

Cleanup design key points -

Snapshot cleanup needs to handle huge scale of snapshots, but based on my discussion with Jullian that doesn't necessarily be in this milestone so for now the plan is to start with something simple which can later be scaled out in next release.
To start with we can focus only on keeping the golden snapshot, latest snapshot (singular) and any tagged snapshots for the actor while all the other snapshots would be deleted.
If we are not worried about the scale for now, this clean up can be a part of Ateapi where Ateapi will have access to delete the snapshots.

Sneha-at (@Sneha-at)

Edit: this design was superseded by #664 (comment)

I'm taking this over from Sneha-at (@Sneha-at). Below is a summary of the proposed plan for remote snapshot garbage collection,

I'd love to get your thoughts and feedback before moving into implementation.

Note: I'm focusing on GC for external/remote snapshots for now. Local snapshots are being garbage collected in the common case(see

substrate/cmd/atelet/local_checkpoints.go

Line 32 in 24b997c

func pruneLocalCheckpointDir(ctx context.Context, dir string) {

) (we still need to audit whether all potential cases where the local snapshots should be cleared are covered, though)

Scope & Context

This design focuses strictly on external/remote snapshots stored in object storage (GCS/S3).

Local snapshots are already pruned on-node for the common cases (see local_checkpoints.go#L32, triggered during Checkpoint and UploadPausedCheckpoint). We still need a follow-up audit to verify all local edge cases are covered, but that is orthogonal to remote GC.
External snapshots currently leak: every checkpoint uploaded to object storage remains there indefinitely once superseded or once the actor is deleted.

Non-goals for v1

To keep the initial implementation focused and avoid scope creep:

No user-facing retentionPolicy: no time-based TTLs or "keep last N snapshots" settings.
No signed URL deletion flow: we won't pass pre-signed deletion URLs through the API.

Retention rule:

A remote snapshot is considered live if and only if it is referenced by either:

An Actor (as its status.latest_snapshot).
An ActorSnapshotTag (as its snapshot target).

Everything else is garbage and eligible for collection.

Note that golden snapshots meet the retention criteria above, because it's pointed to by the golden actor. In the future, we should make this more robust.

Storage Layer: FK-enforced retention

Snapshot retention will be enforced by foreign keys
- Add latest_snapshot_atespace, latest_snapshot_name to actors table with a FOREIGN KEY … ON DELETE RESTRICT to actor_snapshots
- DELETE FROM actor_snapshots then fails with a FK violation if the snapshot is tagged or is still some Actor's latest snapshot
New table actor_snapshot_deletions as an async deletion queue: that will hold the to-be-deleted snapshot uris

Why do we need to project snapshot_atespace/name in `actors` table?

A snapshot is not private to one Actor. N actors cloned from one tag all point at the same row until each takes its own first suspend.
hat makes the snapshot garbage collection a cross-actor operation, and the tag is not a sufficient guard -> because tags can be deleted via DeleteActorSnapshotTag RPC:

So, imagine the following scenario:

Create Actors A and B from tag T. Both get latest_snapshot = S.
DeleteActorSnapshotTag(T). S is now untagged.
Suspend A: S is untagged, but referenced by B.

Answering is S referenced by any other actor would require scanning Actors table and the snapshot details are opaque in the actor proto.

Workflow

Decide whether an ActorSnapshot is a candidate for deletion during SuspendActor, DeleteActor and DeleteActorSnapshotTag operations: push candidates to a deletion queue.
* Snapshot retention decision is delegated to the storage layer (this is enforced by foreign keys)
Delete ActorSnapshots asynchronously

SuspendActor Workflow

ateapi                                atelet            postgres      bucket
  │  Checkpoint ──────────────────────►│                                 │
  │                                    │── upload gen N ────────────────►│
  │◄───────────────────────────────────│                                 │
  │  CreateActorSnapshot(gen N) ─────────────────────────►│              │
  │  UpdateActor: latest = gen N ────────────────────────►│              │
  │                                                       │              │
  │  CollectActorSnapshot(gen N-1) ──────────────────────►│              │
  │      ┌─ SINGLE TRANSACTION ───────────────────────────┐  │              │
  │      │ DELETE actor_snapshots     ← FKs decide     │  │              │
  │      │ INSERT actor_snapshot_deletions             │  │              │
  │      └─────────────────────────────────────────────┘  │              │
  │  ◄── ErrFKViolation if tagged or still a       │              │
  │      sibling actor's latest → skip, nothing queued    │              │
  │                                                                      │
  ▼

DeleteActor Workflow

DeleteActor
  │  [...]

  │  DELETE actors row ──────────────────────────────────►│ postgres
  │        └─ releases this actor's latest_snapshot FK    │
  │                                                       │
  │  CollectActorSnapshot(latest) ───────────────────────►│
  │      ┌─ ONE TRANSACTION ───────────────────────────┐  │
  │      │ DELETE actor_snapshots     ← FKs decide     │  │
  │      │ INSERT actor_snapshot_deletions             │  │
  │      └─────────────────────────────────────────────┘  │
  │                                                       │
  │  ◄── ErrFKViolation if tagged or still a              │
  │      sibling actor's latest → skip, nothing queued    │
  │
  ▼

DeleteActorSnapshotTag workflow

DeleteActorSnapshotTag                                    postgres
  │                                                          │
  │  DELETE actor_snapshot_tags ────────────────────────────►│
  │      RETURNING proto → tag.snapshot                      │
  │      releases this tag's snapshot FK                     │
  │                                                          │
  │  CollectActorSnapshot(tag.snapshot) ────────────────────►│
  │      ┌─ ONE TRANSACTION ──────────────────────────┐      │
  │      │ DELETE actor_snapshots     ← FKs decide    │      │
  │      │ INSERT actor_snapshot_deletions            │      │
  │      └────────────────────────────────────────────┘      │
  │                                                          │
  │  ◄── ErrFKViolation if the snapshot is still an          │
  │      Actor's latest, or another tag names it             │
  │      → skip, nothing queued                              │
  │                                                          │
  ▼

Background periodic collector

A periodic worker in ateapi processes queued deletions asynchronously:

Batches pending rows from actor_snapshot_deletions.
Deletes the remote snapshot artifacts at snapshot_uri from object storage (GCS/S3).
On success, deletes the queue row. On failure, records attempts / last_error and retries with backoff.

Open Questions

Should ateapi delete the snapshots directly, instead of delegating to atelet?
- Having ateapi delete directly via cloud SDKs (GCS/S3) avoids unnecessary RPC hops
- Delegating to atelet avoids granting storage bucket deletion credentials to ateapi, but introduces extra network coupling and requires finding an active atelet to act as a proxy
Do we need a GC that scans the whole snapshot table in the future? The proposed GC is event-driven, so it doesn't self heal:
* In the proposed workflows, mutating the primary resource and running CollectActorSnapshot are separate transactions, so if ateapi crashes after the actor was deleted/suspended but before we call CollectActorSnapshot, we would leak that snapshot forever.

Zoe Zhao (@zoez7)

I also audited where we are be leaking local snapshots:

Every delete that doesn't reach a successful atelet call leaks the local snapshot.
atelet is the only thing that can delete node-local snapshots today, and the
control plane reaches it only through Status.WorkerAssignment (e.g.

substrate/cmd/ateapi/internal/controlapi/workflow_delete.go

Lines 116 to 120 in 75c9b14

    
           assignment := actor.GetStatus().GetWorkerAssignment() 
        
           if assignment == nil { 
        
           	slog.InfoContext(ctx, "actor has no worker assignment, skipping atlet terminate request", slog.Any("actor", actorRef)) 
        
           	return nil 
        
           }

)):

running -> force-delete: atelet's Terminate() ran but didn't prune snapshots. Fixed by Delete local snapshots when an actor is terminated #1246.
paused -> delete / crashed: Terminate is never called, because pause finalize and crashActor both clear WorkerAssignment first.
worker pod gone -> delete: delete treats a missing pod as already terminated and skips atelet.
ActorCrashedMetadata, so the actor never crashes and never leaves SUSPENDING. It keeps the snapshot, and deleting the actor hits the nil-assignment skip in the control plane.

pruneLocalCheckpoints failures are silent (pointed out by Zoe Zhao (@zoez7) in Delete local snapshots when an actor is terminated #1246): it logs and
moves on. So a failure on Delete operations is permanent
(after Delete local snapshots when an actor is terminated #1246) atelet only prunes on the node it runs on. OK today because NodeVmsWithLocalSnapshots holds at most one entry, but the fix needs to be extendible.

Delete local snapshots when an actor is terminated (#1246)

Eitan Yarmush (@EItanya)

The proposal in #664 (comment) introduced yet another FK, which we've been trying to avoid, given the scale we want to support.

So, we took a step back and rethought how snapshots and tags should be stored/represented in the system in the first milestone. This is the updated proposal for modelling snapshots/tags in the API and how to garbage collect them:

cc Eitan Yarmush (@EItanya) Julian Gutierrez Oschmann (@juli4n) Dmitry Berkovich (@dberkov)

TL;DR

We propose a snapshot ownership model that is single and static:

An Actor owns the snapshot it writes at suspend
A tag owns a copy taken at tag creation,
An actor cloned from a tag borrows the tag's snapshot until its own first suspend.

Garbage Collection: whoever created/owns the snapshot is the only one who ever deletes them.

This proposal:

Drops table actor_snapshots
Keeps table actor_snapshot_tags at the size it already is on main, and keeps actor_snapshot_tags_atespace_fk
Drops GetActorSnapshot and turns ListActorSnapshots into ListActorSnapshotTags: tags become the only named, listable handle on a snapshot. Keeps the 4 tag RPCs
Adds an object copy at tag creation, and an owned versus borrowed distinction on the Actor
Adds synchronous external snapshot deletion at actor suspend, at actor delete, and at tag delete

Current State

DB Model

Snapshots are referenced by 3 tables:

       actors                    actor_snapshots            actor_snapshot_tags
 +--------------------+     +---------------------+    +------------------------+
 | atespace, name PK  |     | atespace, name  PK  |<---| atespace, name     PK  |
 | uid, version       |     | uid, version        | FK | snapshot_atespace      |
 | proto:             |     | proto:              |    | snapshot_name          |
 |  status.latest_    |---->|  status.snapshot_uri|    | proto: scope           |
 |    snapshot        | no  |  status.content_    |    +------------------------+
 |  status.source_    | FK  |    scope            |      client created only
 |    snapshot        |     |  status.actor_      |      an optional alias
 +--------------------+     |    template_uid     |
   one row per actor        +---------------------+

Ownership Model

None. Actor, Tag and Golden Actor all reference a snapshot and none of them owns it today.

Snapshot Lifecycle

Birth

SuspendActor stores the snapshot in GCS/S3 and in the DB
Snapshot is born untagged

Tagging

Tags are only an alias. They carry no retention meaning at all
Tag scope is either ATESPACE, readable only inside its own atespace, or PUBLISHED, clonable from anywhere
A tag lives in its snapshot's atespace, and is created by a client after the fact

Cloning

CreateActor points actor.status.latest_snapshot at an existing tagged snapshot
Cloning never writes to GCS

Reading

Resume dereferences actor.status.latest_snapshot into the snapshot row and pulls snapshot_uri and content_scope off it

GC Eligibility

Snapshot is not referenced by any tags or actors → requires search across multiple tables (including opaque fields)

Proposal

DB Model

actor_snapshots is dropped. The fields that lived in its proto move onto the Actor and onto the tag tables, as an inline ExternalSnapshot message (snapshot_uri + content_scope) on whoever holds the snapshot. actor_snapshot_tags loses its FK into actor_snapshots, its index, and its two snapshot columns

             actors                            actor_snapshot_tags
 +--------------------------------+   +----------------------------------+
 | atespace, name  PK             |   | atespace, name        PK         |
 | uid, version                   |   | uid, version                     |
 | proto:                         |   | proto:                           |
 |  status.external_snapshot      |   |  scope ATESPACE or PUBLISHED     |
 |    snapshot_uri                |   |  status.snapshot                 |
 |    content_scope               |   |    snapshot_uri                  |
 |  status.in_progress_snapshot_  |   |    content_scope                 |
 |    name                        |   |  status.in_progress_snapshot_uri |
 |  status.current_snapshot_tag   |   |  status.actor_template_uid       |
 |    set only while borrowing    |   |  status.source_actor_uid         |
 +--------------------------------+   +----------------------------------+
                 |                                     |
                 | deletes iff                         | deletes iff user calls
                 | current_snapshot_tag is unset       | DeleteActorSnapshotTag()
                 v                                     v

status.current_snapshot_tag is a pointer inside the Actor's proto, not an FK: nothing in the schema stops the tag from being deleted first. The only FK left is actor_snapshot_tags_atespace_fk, which is what keeps an Atespace from being deleted out from under its tags.

Ownership Model

Ownership is single and static: the owner is fixed when the objects are written, and never moves. A tag does not take a snapshot over from an Actor, it gets its own copy.

Snapshot Type	Owned By	Created when	Eligible for GC when
Actor	Actor, via `actor.status.external_snapshot`	Actor is suspended	at the Actor's next successful `SuspendActor`, and at `DeleteActor`
Tag	Tag, via `tag.status.snapshot`	`CreateActorSnapshotTag` copies the Actor's snapshot	At `DeleteActorSnapshotTag`
Borrowed	still the Tag	`CreateActor` from a tag; no objects are written	never by the clone — it stops borrowing at its own first suspend
Golden	the golden Actor's `status.external_snapshot`	Golden Actor is suspended	When golden actor is deleted

Snapshot Lifecycle

Birth

SuspendActor stores the snapshot in GCS/S3 and writes its URI onto the Actor row
No snapshot row is created. There is no actor_snapshots table
The snapshot this suspend replaces is deleted, unless the Actor was only borrowing it from a tag
The Actor stops borrowing here: status.current_snapshot_tag is cleared in the same commit that records the new snapshot

Tagging

CreateActorSnapshotTag(T, actor=A) is kept, and names the Actor to tag rather than a snapshot resource that no longer exists
It is a workflow, because it now spans two transactions around an object copy:
1. Reserve — mint a destination and record it in status.in_progress_snapshot_uri, before a single object is written
2. Copy — copy the Actor's snapshot prefix, server-side; the bytes never transit ate-api
3. Finalize — move the destination into status.snapshot and clear the in-progress field
The Actor must be SUSPENDED and hold a snapshot: a running or suspending Actor's is either stale or still being written
The workflow holds the Actor's lease, which serializes it against a suspend of the same Actor
Destinations are minted, never derived: a fresh tag- prefixed UUID, recorded on the row and only ever read back. Nothing can compute its way onto another tag's objects, and a recreated tag never inherits what its predecessor stranded
A retry adopts the pending row and re-copies to the URI it already names, gated on status.source_actor_uid: adopting another Actor's pending create would interleave two sources into one prefix
A pending tag is not usable — CreateActor refuses to seed from one and UpdateActorSnapshotTag refuses to change its scope, since both would hand out content that is still being written or may never be
Scope is required at creation, ATESPACE or PUBLISHED, and can be changed afterwards via UpdateActorSnapshotTag

Cloning

CreateActor copies the tag's ExternalSnapshot into actor.status.external_snapshot and records the tag in actor.status.current_snapshot_tag
Cloning never writes to GCS: the clone borrows the tag's copy until its own first suspend

GC Eligibility

Three release points, all synchronous.

Event	Eligible for GC	When
`SuspendActor`	the snapshot this suspend replaces	`current_snapshot_tag` was unset
`DeleteActor`	the Actor's snapshot, plus one an interrupted suspend left mid-write	`current_snapshot_tag` is unset
`DeleteActorSnapshotTag`	the tag's copy, plus one an unfinished create left mid-copy	Always (tag always owns its copy)

Every release runs before the row that names the objects is overwritten or dropped, so an interrupted release is rediscoverable and the retry deletes whatever is left; the opposite order would drop the only handle on them. A failure fails the whole RPC and the client retries with the same arguments. The cost is that a crash between the release and the commit can leave objects no row names — strictly better than losing the ability to ever delete them.

One case still leaks, and is marked TODO: an in-progress snapshot whose ActorTemplate no longer resolves. The template's storageLocation is the only place its URI can be derived from, so without it the choice is between leaking the objects and wedging the Actor in DELETING forever.

Open Questions / Future Work

When is a snapshot cloned?
- For M2: Only when tagging a snapshot (during CreateActorSnapshotTag())
If a tag is deleted, it will also delete the underlying snapshot and the actor will be unrecoverable
- Decision:
  - For M2, we'll document that tags shouldn't be deleted while clones of them exist.
  - Future milestones: prevent tag deletion if at least an actor references it
If an actor has external volumes, what does it mean to fork/clone?
- Decision: For M2: do not use external volume with tags
Do we need a separate method to tag a snapshot?
- Decision: yes, CreateActorSnapshotTag(actor=A) stays, and SuspendActor gains no tag parameter. Tagging is a copy that can take a while, and folding it into suspend would hold the actor's lease for the length of it
- The residual race is that the tag captures whichever snapshot the Actor holds when the workflow runs, so a suspend that lands first moves what gets tagged. That is inherent to naming an Actor rather than a snapshot
A CreateActor racing a DeleteActorSnapshotTag can seed from content that is going away: the tag stays resolvable while its snapshot is being collected
- Decision: accepted for M2, same fix as tag deletion above

Garbage Collect snapshots and remove the snapshot resource (#1417)

Call the generated validation fns for ActorSnapshotTag methods (#1488)

Rename ActorSnapshotTag to Tag (#1491)

Move DeleteTag orchestration to a workflow (agent-substrate#1720)

	assignment := actor.GetStatus().GetWorkerAssignment()
	if assignment == nil {
	slog.InfoContext(ctx, "actor has no worker assignment, skipping atlet terminate request", slog.Any("actor", actorRef))
	return nil
	}

Add retention policy and garbage collection for ActorSnapshots #664

Description

Problem

Retention semantics

Collection design

Out of scope

Acceptance criteria

Activity

thockin commented on Aug 17, 2026

igooch commented on Aug 17, 2026

Sneha-at commented on Aug 19, 2026

laoj2 commented on Aug 26, 2026

Edit: this design was superseded by #664 (comment)

Scope & Context

Non-goals for v1

Retention rule:

Storage Layer: FK-enforced retention

Why do we need to project snapshot_atespace/name in actors table?

Workflow

SuspendActor Workflow

DeleteActor Workflow

DeleteActorSnapshotTag workflow

Background periodic collector

Open Questions

laoj2 commented on Aug 27, 2026

laoj2 commented on Sep 1, 2026

TL;DR

Current State

DB Model

Ownership Model

Snapshot Lifecycle

Birth

Tagging

Cloning

Reading

GC Eligibility

Proposal

DB Model

Ownership Model

Snapshot Lifecycle

Birth

Tagging

Cloning

GC Eligibility

Open Questions / Future Work

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Why do we need to project snapshot_atespace/name in `actors` table?