Taskstream-Historie und Aufbewahrung verwalten

Workspace begrenzt Taskstream-Ausführungsnachweise, bewahrt sie nach festen Regeln auf und kann sie durch einen Legal Hold schützen. Prüfen Sie hier die Job-Historie, sperren Sie einen Nachweis oder beurteilen Sie, ob sich ein Job sicher löschen lässt.

Taskstream bleibt im eingeschränkten Sicherheitsbetrieb. Verwenden Sie die History- und Retention-Aktionen nur über den freigegebenen Trusted-Operator-Zugang. Im Standardbetrieb bleiben externe mutierende Taskstream-Routen geschlossen.

Welche Nachweise Workspace speichert

Neue öffentliche Job-Logs enthalten eine stabile Ergebnisklasse und, falls vorhanden, die zugehörige Occurrence- und Attempt-ID. Workspace begrenzt das Resultat auf 64 KiB. Freie Fehlermeldungen, Credential-Werte, SQL-Details, Dateipfade sowie DNS-, TLS- oder Runtime-Fehler erscheinen nicht in der öffentlichen Historie.

Workspace kennzeichnet abgeschnittene Resultate und Fehlerquellen getrennt. Ältere Logs ohne belegte Sanitization-Version bleiben aus der neuen öffentlichen History ausgeblendet. Workspace ergänzt diese Evidence nicht nachträglich.

Fristen

Ein tenantgebundener Wartungsjob entfernt abgelaufene, nicht geschützte Nachweise in kleinen Batches. Archivierung verkürzt keine Frist. Sie bleibt der normale Weg, abgeschlossene Jobs aus der aktiven Liste zu nehmen.

Historie lesen

GET /api/v1/jobs/{jobId}/logs unterstützt einen opaken Keyset-Cursor. Nutzen Sie cursor für neue Integrationen. Das Standardlimit beträgt 25, das Maximum

1. Die Response liefert den nächsten Cursor unter

meta.cursorPagination.nextCursor. Ein Cursor ändert weder den Tenant noch die Job-ID.

Bestehende Clients können page und count oder offset und limit weiterverwenden. Auch dieser Pfad liefert höchstens 200 Einträge pro Request.

Legal Hold setzen und freigeben

Ein Legal Hold schützt die Jobdefinition, technische Controls, Logs, Occurrences, Attempts und referenzierte Autorisierungsnachweise. Verwenden Sie dafür ausschließlich eine Identität mit taskstream:jobs:retention.

Der Grund muss nach Normalisierung zwischen 1 und 512 Byte lang sein. Schreiben Sie eine fachlich nachvollziehbare Begründung, aber keine Passwörter, Tokens oder anderen Credential-Werte hinein. Workspace speichert Actor, Zeitpunkt und Audit-Korrelation. Eine Freigabe ergänzt eigene Release-Evidence und verändert den ursprünglichen Hold-Grund nicht.

Pro Job kann nur ein Hold aktiv sein. Eine Freigabe ohne aktiven Hold und ein zweiter paralleler Hold enden mit einem stabilen Konflikt.

Löschung beurteilen

Workspace blockiert einen Log-Reset bei aktivem Hold. Die Joblöschung ist zusätzlich gesperrt, solange eine Occurrence nicht terminal, ein Attempt aktiv oder ein Autorisierungsnachweis weiterhin referenziert ist.

Prüfen Sie vor einer Löschung:

1. Archivieren Sie den Job, wenn Sie ihn nur aus der aktiven Liste entfernen möchten.
2. Prüfen Sie, ob ein Legal Hold aktiv ist.
3. Prüfen Sie laufende oder wartende Ausführungen.
4. Geben Sie einen Hold nur mit fachlicher Freigabe und dokumentiertem Grund frei.
5. Löschen Sie den Job erst, wenn Workspace keine Retention-Sperre mehr meldet.

TASKSTREAM_RETENTION_BLOCKED bedeutet, dass Evidence weiterhin geschützt oder referenziert ist. TASKSTREAM_RETENTION_UNAVAILABLE bedeutet, dass Workspace den Schutzvertrag nicht sicher lesen konnte. Wiederholen Sie in diesem Fall keine Löschung über direkte Datenbankzugriffe.

Erfolg prüfen

Die Prüfung ist abgeschlossen, wenn die History nur stabile, begrenzte Einträge liefert, der Hold mit Actor und Grund bestätigt ist und Reset oder Delete während des Holds mit einem Retention-Konflikt endet. Nach einer freigegebenen Release-Aktion bleibt der abgeschlossene Hold als Auditnachweis erhalten.

Diese Funktion ersetzt keine rechtliche Bewertung Ihrer Aufbewahrungs- oder Löschpflichten.