Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#5,909 1 comentario 1 reacción 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@eersnington ya está trabajando en esto.

Desde el 22/10/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, node.js, postgresql, rust, typescript
Área
backend, databases, distributed-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
6.3k
Forks
280
Merge medio
1 d 9 h
PR fusionados (30 d)
53

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/rivet

Todos los issues de rivet-dev/rivet

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.