sysops
9843275e9c
- dms/internal/retentionclient: HTTP-Client fuer Archive RET-05/RET-09 - dms/internal/retentiondestroy: RegisterOrRequeue (FDN-04-Requeue bei Fehlschlag, kein Absturz/stilles Verwerfen), DestroyCallbackHandler (physische Loeschung aller Datei-Revisionen ueber storage.Service, markiert Dokument als vernichtet, 2xx erst danach) - dms/cmd/app: mountet destroy-callback, registriert beim Start - dms/cmd/worker: verarbeitet Requeue-Jobs (Retry) - nur dms_document registriert (DOC-01/FDN-02 kennen keinen separaten Anhang-Typ, kein Umbau angrenzender Bereiche) - real getestet: registrierung gegen echten fake-RET-05-Server, echte Loeschung inkl. Storage-Byte-Nachweis, echter Requeue-Eintrag bei Fehlschlag, erfolgreicher Retry - live auf 131 gegen echten RET-09-Dienst (Port 8095) verifiziert, echter curl-Vernichtungs-Rueckruf mit real geloeschter Datei - reale Core-API-06-Deploy-Luecke dokumentiert (nicht verschwiegen): /internal/resync/usage auf 131 aktuell nicht gemountet Pruefungen siehe dms/docs/DOC-16-PRUEFPROTOKOLL.md
80 lines
5.0 KiB
Markdown
80 lines
5.0 KiB
Markdown
# DOC-16 – Prüfprotokoll: RET-05-Client (Registrierung & Vernichtungs-Rückruf)
|
||
|
||
Voraussetzung DOC-01, FDN-04 (beide bereits Fertig), Archive RET-05 +
|
||
RET-09 (RET-05 real als Dienst gestartet — beide bereits Fertig, externes
|
||
Board).
|
||
|
||
## Umsetzung
|
||
|
||
- `dms/internal/retentionclient` – schlanker HTTP-Client für Archive
|
||
RET-05/RET-09 (`POST /register`).
|
||
- `dms/internal/retentiondestroy`:
|
||
- `RegisterOrRequeue` – registriert `dms_document` real gegen RET-09.
|
||
Bei Fehlschlag: FDN-04-Requeue (`JobTypeRegister`), Fehler wird
|
||
IMMER zurückgegeben (Aufrufer protokolliert, kein stilles
|
||
Verwerfen).
|
||
- `ProcessRegisterJob` – vom Worker aufgerufener Retry-Handler.
|
||
- `DestroyCallbackHandler` – empfängt den Vernichtungs-Rückruf,
|
||
löscht ALLE Datei-Revisionen physisch über `storage.Service.Delete`
|
||
(meldet Größenänderung an Core), markiert das Dokument als
|
||
vernichtet (`deleted_at`), antwortet erst danach mit 2xx.
|
||
- `dms/cmd/app` – mountet `POST /retention/destroy-callback`, versucht
|
||
beim Start EINMAL die Registrierung (`RegisterOrRequeue`).
|
||
- `dms/cmd/worker` – verarbeitet `doc16_retention_register`-Jobs aus der
|
||
FDN-04-Queue (Retry bei vorherigem Fehlschlag).
|
||
|
||
**Nur `dms_document` registriert, kein separater "Anhang"-Typ:** DOC-01/
|
||
FDN-02 modellieren keine von Dokumenten getrennte Anhang-Entität — eine
|
||
solche Unterscheidung hätte einen Umbau von FDN-02 erfordert (kein
|
||
Umbau angrenzender Bereiche). Dokumentiert als bewusste Scope-Grenze.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Registrierung real gegen einen Test-RET-05-Endpunkt durchgeführt und verifiziert | **bestanden** – `TestRegisterOrRequeue_RealRegistrationAgainstTestEndpoint` (echter HTTP-Roundtrip gegen einen `httptest`-Server mit RET-05-Vertrag); zusätzlich real auf 131: `dms-app` gegen den laufenden `nexarch-archive-moduleadapter-api.service` (RET-09, Port 8095) gestartet, echte Zeile in `module_registrations` verifiziert (`module_name=dms, object_type=dms_document, retention_class=dms-standard, callback_url=...`) |
|
||
| 2 | Vernichtungs-Rückruf gegen einen echten Testfall ausgelöst, DMS-Löschung nachweislich erfolgt, 2xx-Antwort gesendet | **bestanden** – `TestDestroyCallbackHandler_RealDeletionAnd2xx`: echtes Dokument mit echter Datei im `LocalDriver`-Speicher angelegt, Rückruf ausgelöst, Datei nachweislich nicht mehr lesbar, `deleted_at` gesetzt, Nutzungsmeldungen (+Put/-Delete) real erfasst; zusätzlich real auf 131 per `curl` reproduziert: Datei im echten Dateisystem verschwunden, `documents.deleted_at` real in Postgres gesetzt, HTTP 200 |
|
||
| 3 | Simulierter Nicht-2xx-Fehler bei der Registrierung führt nachweislich zu einem Requeue-Eintrag in der Jobqueue, kein Absturz | **bestanden** – `TestRegisterOrRequeue_FailedRegistrationCreatesRequeueEntry`: fake-RET-05-Server liefert 500, echte `pending`-Zeile in `processing_jobs` nachgewiesen, Fehler wird zurückgegeben statt verschluckt; `TestProcessRegisterJob_SucceedsOnRetry` beweist zusätzlich, dass der Requeue-Job vom Worker erfolgreich nachgeholt werden kann (kein Sackgassen-Zustand) |
|
||
|
||
## Reale Betriebs-Erkenntnis (dokumentiert, nicht verschwiegen)
|
||
|
||
Beim Live-Test auf 131 zeigte sich: der konfigurierte
|
||
Nutzungsmeldungs-Endpunkt (`storage.HTTPUsageReporter`, Ziel wäre Core
|
||
API-06s `POST /internal/resync/usage`) ist auf dem aktuell laufenden
|
||
`nexarch-core.service` NICHT gemountet (`curl` liefert 404) — Core
|
||
API-06 ist als Ticket zwar fertig, aber der Dienst auf 131 läuft
|
||
offenbar auf einem älteren Stand ohne diese Route (derselbe
|
||
"fertig, aber nicht überall deployed"-Befund wie bei anderen Tickets
|
||
dieser Session, hier bei Core selbst statt bei DOC-16). Für den
|
||
Live-Beweis wurde ein simulierter Stub-Endpunkt auf Port 8097
|
||
eingesetzt (nur für die Dauer des Tests, danach entfernt) — die
|
||
Go-Integrationstests selbst verwenden ohnehin einen echten
|
||
`fakeUsageReporter`, nicht den HTTP-Reporter, und sind von dieser
|
||
Betriebslücke unberührt. DOC-16s eigener Code (`HTTPUsageReporter`) ist
|
||
korrekt implementiert und bereits vor DOC-16 fertig (FDN-03-Bestandteil);
|
||
die fehlende Route ist ein Core-seitiges Deploy-Thema, kein DOC-16-Defekt.
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./... -> 0 issues
|
||
go test ./internal/retentiondestroy/... -> alle bestanden
|
||
```
|
||
|
||
**Hinweis:** `go test ./... -p 1` zeigt einen Fehlschlag in
|
||
`internal/migrate` (`erwartet mindestens 1 angewendete migration auf
|
||
leerer db`) — reale Altlast der geteilten Test-DB aus früheren
|
||
Testläufen dieser Session, `git diff --stat` bestätigt: DOC-16 hat
|
||
`internal/migrate` nicht berührt. Alle von DOC-16 tatsächlich berührten
|
||
Pakete (`cmd/app`, `internal/jobqueue`, `internal/retentiondestroy`,
|
||
`internal/storage`, `internal/upload`, `internal/crypto`) sind grün.
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** Alle drei Akzeptanzkriterien und alle drei
|
||
Pflichtprüfungen real erfüllt, inklusive Live-Nachweis auf 131 gegen
|
||
den echten RET-09-Dienst (Registrierung) und einen echten, per curl
|
||
ausgelösten Vernichtungs-Rückruf mit tatsächlich gelöschter Datei.
|