GNL
Dokümanlar menüsü
Core · Ücretsiz@gnldev/durable

GDPR / PII silme (purge)

Run/thread journal izini kalıcı sil (purgeRun/purgeThread) — journal'ın append-only felsefesinin yasal silme için tek istisnası. purgeRun özyineleme ile alt-agent/network çocuklarını da kaskad siler.

Ne işe yarar / ne zaman kullanılır#

GNL journal'ı normalde append-only'dır (bkz. deterministik replay, exactly-once araçlar) — kayıtlar silinmez, üzerine yazılmaz. Ancak bir kullanıcı GDPR kapsamında "beni unut" talebinde bulunduğunda ya da bir run'a kazayla PII (kişisel veri) girdiğinde, bu izin kalıcı olarak silinmesi gerekir. purgeRun ve purgeThread tam bu senaryo içindir: journal'ın append-only kuralına bilinçli ve tek istisna olarak, ilgili run'ın veya thread'in tüm anahtar öneki (model/tool/input/wf/proc/cfg/memory girdileri) kalıcı olarak silinir — geri alınamaz.

Kurulum / import#

import
import { purgeRun, purgeThread } from '@gnldev/durable';

Ayrı bir alt-paket yolu yok — purgeRun, purgeThread ve sweepRuns doğrudan @gnldev/durable kök export'undan gelir. Kullandığınız journal'ın (SqliteStorage, PostgresStorage, InMemoryStorage) deletePrefix portunu desteklemesi gerekir — dört yerleşik adaptör (InMemory/SQLite/Postgres/Redis) de sağlar; desteklemeyen bir journal verilirse net bir hata fırlatılır.

Adım adım kullanım#

1. Bir run'ın tüm izini (o run'a ait tüm runId:* anahtarları + memory marker'ı) kalıcı silin:

run purge
import { purgeRun, purgeThread } from '@gnldev/durable';

const removed = await purgeRun(journal, 'run-123');
// removed: the number of journal keys deleted (parent + EVERY sub-agent/network child)

Silmeden önce, eğer run bütçe sayacına eklenmişse (bkz. bütçe/kota) bu maliyet sayaçtan otomatik düşülür — aksi halde purge sonrası __usage__ bayat kalır ve silinen run'ın maliyeti hayalet olarak sayılmaya devam eder. Bu düşme yalnız run gerçekten sayaca eklenmişse yapılır; hiç sayılmamış (ör. hâlâ askıda onay bekleyen) bir run'ı yanlışlıkla eksiye düşürmez.

purgeRun ÖZYİNELEMELİDİR: bir run başka run'lara dallanmış olabilir — dinamik multi-agent yönlendirmenin (runNetwork) çocukları (net:<runId>:<i>) ya da statik agent_<ad> tool çağrılarının açtığı alt-agent run'ları (agent:<toolCallId>). Silmeden ÖNCE parent'ın journal'ı taranır (tool entry'lerinden ve net: önekli anahtarlardan), bulunan her çocuk kendi çocuklarıyla birlikte (hangi seviyede olursa olsun) kaskad silinir — döngü/tekrar emniyeti dahildir. Sonuç: bir kullanıcının GDPR "beni unut" talebi, o kullanıcının PII'si alt-agent çıktılarına sızmış olsa bile hiçbir seviyede yetim iz bırakmaz.

2. Bir thread'in (BasicMemory tabanlı) journal izini silin:

thread purge
await purgeThread(journal, 'thread-abc');
// deletes the mem:thread-abc:* keys
Zengin memory store'lar
purgeThread, journal-tabanlı BasicMemory izini (mem:<threadId>:*) siler. Ayrı bir zengin memory store kullanıyorsanız (ör. vektör tabanlı), o store'un kendi silme API'sini (AgentMemory.deleteThread) ayrıca çağırmanız gerekir.

3. Studio üzerinden (yazılabilir journal + operatör yetkisi gerekir) tek bir run'ı silin:

Studio — run purge
DELETE /runs/:id
 { ok: true, deleted: <number of keys removed> }

API referansı#

fnpurgeRun

(journal, runId, seen?) → Promise<number>. Bir run'ın TÜM izini (<runId>:* + memory marker'ı) kalıcı siler; ÖZYİNELEMELİDİR — alt-agent (agent:<toolCallId>) ve network (net:<runId>:<i>) çocuklarını hangi seviyede olursa olsun kaskad siler (döngü emniyetli). Silmeden önce bütçe sayacından run maliyetini düşer (best-effort).

fnpurgeThread

(journal, threadId) → Promise<number>. Bir thread'in BasicMemory izini (mem:<threadId>:*) kalıcı siler; silinen anahtar sayısını döner.

fnsweepRuns

(journal, { olderThanMs, keepSuspended?, now? }) → Promise<SweepResult>. Retention politikasına göre eski run'ları toplu purgeRun ile siler (bkz. retention/TTL süpürmesi).

Kapsam ve yetki
Studio'daki DELETE /runs/:id, kök seviyesi (organizasyon kapsamsız) bir yönetim ucudur — ham journal üzerinde çalışır. Bu yüzden organizasyona bağlı bir kimlik bu ucu çağıramaz (403 döner); yalnızca organizasyona bağsız bir operatör run purge işlemi yapabilir — aksi halde bağlı kimlik başka bir organizasyonun run'ını da silebilirdi. İşlem geri alınamaz ve aktör + silinen kayıt sayısıyla birlikte run.purge olarak denetim (audit) kaydına düşer.