What happened
Destroying an actor backed by remote SQLite makes the actor inaccessible, but leaves its branch-backed Depot data in PostgreSQL.
This matters because actor destruction is documented as permanently deleting the actor's state, including for account deletion and GDPR cleanup. The retained branch also keeps a refcount of 1, so it does not appear eligible for later garbage collection and may cause storage to grow indefinitely as actors are destroyed.
Reproduction
Standalone script: https://gist.github.com/K-Mistele/a23fbbff713a82799c517abbc78408ca
chmod +x repro-actor-destroy-sqlite.sh
./repro-actor-destroy-sqlite.sh
The script:
- Starts a clean PostgreSQL-backed Rivet Engine.
- Starts a RivetKit registry with
sqlite: "remote".
- Creates an actor and persists a 256 KiB marker in its state.
- Finds the new Depot database branch in PostgreSQL.
- Records the branch rows and refcount.
- Destroys the actor through
DELETE /actors/{actor_id}.
- Queries the same branch again.
Example output:
Before destroy:
branch_rows=39
refcount=1
After destroy:
branch_rows=43
refcount=1
The actor disappears from the active actor list and can no longer be accessed, confirming the destroy operation completed. However, none of the existing branch rows are removed. Additional rows are written during shutdown, and the branch remains referenced.
Expected behavior
Destroying an actor should logically delete its Depot database, decrement the branch refcount, and make the underlying branch data eligible for garbage collection.
Suspected cause
The actor destroy path calls clear_v2_storage_for_destroy, which clears the older actor-ID-keyed Depot layout. Current remote SQLite data uses the branch-backed layout under BR/<branch id>/....
I do not see the destroy path calling depot::conveyer::branch::delete_database, which writes the database tombstone and decrements the branch refcount for the current layout.
What happened
Destroying an actor backed by remote SQLite makes the actor inaccessible, but leaves its branch-backed Depot data in PostgreSQL.
This matters because actor destruction is documented as permanently deleting the actor's state, including for account deletion and GDPR cleanup. The retained branch also keeps a refcount of
1, so it does not appear eligible for later garbage collection and may cause storage to grow indefinitely as actors are destroyed.Reproduction
Standalone script: https://gist.github.com/K-Mistele/a23fbbff713a82799c517abbc78408ca
The script:
sqlite: "remote".DELETE /actors/{actor_id}.Example output:
The actor disappears from the active actor list and can no longer be accessed, confirming the destroy operation completed. However, none of the existing branch rows are removed. Additional rows are written during shutdown, and the branch remains referenced.
Expected behavior
Destroying an actor should logically delete its Depot database, decrement the branch refcount, and make the underlying branch data eligible for garbage collection.
Suspected cause
The actor destroy path calls
clear_v2_storage_for_destroy, which clears the older actor-ID-keyed Depot layout. Current remote SQLite data uses the branch-backed layout underBR/<branch id>/....I do not see the destroy path calling
depot::conveyer::branch::delete_database, which writes the database tombstone and decrements the branch refcount for the current layout.