Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`DELETE /actors/{id}` leaves the destroyed actor's data (workflow step output, queue bodies, state) in engine KV under Depot `DELTA` keys

Aperta
  • Qualcosa non va?
#5,909 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, node.js, postgresql, rust, typescript
Ambito
backend, databases, distributed-systems

Direzione di ricerca

Start by reading the destroy path in actor2/mod.rs, especially ClearKv and clear_v2_storage_for_destroy, then trace how Depot DELTA keys are written and associated with an actor. Check existing destroy and purge tests, and add coverage for workflow output, queue bodies, and actor state. Done means destroying an actor removes its data from engine KV, or the intended retention and purge behavior is documented and covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Environment
  • rivetkit 2.3.27, rivetdev/engine:2.3.27 (self-hosted, Docker), Postgres backend (rivet_engine database)
Expected

destroy.mdx: "The actor's state is permanently deleted." Engine actor2/mod.rs destroy runs
ClearKv + clear_v2_storage_for_destroy. After DELETE /actors/{id} we expect no row in the
engine kv table to contain values written by that actor.

Actual

Unique marker strings written by the actor as (a) a workflow step return value, (b) a queue message
body and (c) actor state are still present in the engine's kv table after destroy — 5 s, 35 s,
30 min and 13.2 h later (5 rows under Depot DELTA keys in the 13.2 h check).

Repro
// probe.ts — `tsx probe.ts` against a local engine whose Postgres is on 127.0.0.1:54329
import { randomUUID } from "node:crypto";
import pg from "pg";
import { actor, setup } from "rivetkit";
import { createClient } from "rivetkit/client";
import { workflow } from "rivetkit/workflow";

const ENDPOINT = "http://127.0.0.1:6420";
const TOKEN = "<admin-token>";
const step = `STEP-${randomUUID()}`, queued = `QUEUE-${randomUUID()}`, stateMark = `STATE-${randomUUID()}`;

const leaky = actor({
  state: { note: "" },
  run: workflow(async (ctx) => {
    const msg = await ctx.queue.next("go");
    await ctx.step("leak", async (s) => {
      s.state.note = stateMark;
      return { note: step, from: JSON.stringify(msg.body) };
    });
    await ctx.queue.next("never");
  }),
  actions: { go: async (c, body: string) => c.queue.send("go", { body }) },
});
const registry = setup({ use: { leaky }, endpoint: ENDPOINT, token: TOKEN, namespace: "default" });
await registry.startAndWait();
const client = createClient<typeof registry>({ endpoint: ENDPOINT, token: TOKEN, namespace: "default" });
const h = client.leaky.getOrCreate([`probe-${Date.now()}`]);
await h.go(queued);

const db = new pg.Pool({ connectionString: "postgres://rivet:[email protected]:54329/rivet_engine" });
const scan = async (label: string) => {
  const { rows } = await db.query<{ key: Buffer; value: Buffer }>("SELECT key, value FROM kv");
  const hay = Buffer.concat(rows.flatMap((r) => [r.key, r.value]));
  console.log(label, { step: hay.includes(step), queue: hay.includes(queued), state: hay.includes(stateMark) });
};
await new Promise((r) => setTimeout(r, 3000));
await scan("before destroy");
const id = await h.resolve();
await fetch(`${ENDPOINT}/actors/${id}?namespace=default`, { method: "DELETE", headers: { authorization: `Bearer ${TOKEN}` } });
await new Promise((r) => setTimeout(r, 35000));
await scan("35 s after DELETE /actors");
Measured
  • All three markers present after destroy at +5 s and +35 s; rows not reclaimed within 30 min.
  • Long check: actor destroyed, markers still present 13.2 h later, 5 rows under Depot DELTA keys.
  • In our purge integration test (destroy every actor of a deleted tenant, then scan engine KV for
    that tenant's identifiers): 79 / 83 / 92 matching rows across three runs, growing with the shared
    engine database. The actors themselves are gone (no live entry), only the data stays.
  • rivet_engine grew to 27 MB / 60k KV rows over a small spike (2 tenants, ~10 workflows).
Question / suggested fix

Should destroy (or a later GC) delete the actor's Depot DELTA keys? If retention is intended,
please document how long and how to purge — we need it for data-deletion requests (GDPR erasure).
Today we can't rely on DELETE /actors for deletion and avoid touching engine tables directly.

Lingua principale
Rust
Stelle
6.3k
Fork
279
Merge medio
1g 9h
PR unite (30g)
53

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rivet-dev/rivet

Tutte le issue di rivet-dev/rivet

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.