sysops
d6e9412043
- Merge API-02 (bereits Vorfahre), AUD-01, LIC-03 in API-06-Branch, um echte Produktionsimplementierungen fuer resync.Handler zu erhalten (moduleregistry.Registry, audit.Log, usage.Store) - go.mod/go.sum/ scripts/reset-test-env.sh additiv zusammengefuehrt, keine Logikkonflikte - cmd/resync-api: startet internal/resync.Handler (API-06) als eigenstaendigen HTTP-Dienst, kleiner auditAdapter fuer Signatur- Anpassung (kein neuer Fachcode) - reines Wiring, kein Diff an internal/resync|audit|usage|moduleregistry (verifiziert) - real deployed auf 131, end-zu-ende per curl mit echtem, ueber moduleregistry.Registry.Provision ausgestelltem Service-Credential: angewendetes usage-delta real in usage_counters bestaetigt, falsches Credential -> 401 - reale Grant-Luecke gefunden und behoben (nexarch_core auf modules/ module_credentials/audit_events/feature_flags/usage_counters/ resync_*_buffer), ueber information_schema verifiziert Pruefungen siehe docs/API-11-PRUEFPROTOKOLL.md
77 lines
4.0 KiB
Markdown
77 lines
4.0 KiB
Markdown
# API-11 – Prüfprotokoll: Wiederanlauf-Nachsynchronisierungs-Endpunkt starten (API-06 als laufender Dienst)
|
||
|
||
Voraussetzung API-06 – bereits Fertig, hier UNVERÄNDERT.
|
||
|
||
## Reines Wiring, keine neue Logik
|
||
|
||
`git diff --stat internal/resync/ internal/audit/ internal/usage/ internal/moduleregistry/`
|
||
liefert KEINEN Diff gegenüber den jeweiligen Ticket-Ständen. `API-11`
|
||
fügt ausschließlich `cmd/resync-api/main.go` hinzu — inklusive eines
|
||
kleinen `auditAdapter`, der `resync.AuditRecorder` (einzelne Felder)
|
||
auf `audit.Log.Record` (Event-Struct) abbildet. Das ist reine
|
||
Signatur-Anpassung, keine neue Geschäftslogik.
|
||
|
||
## Root Cause (dokumentiert)
|
||
|
||
`cmd/core/main.go` ist seit TEN-01 minimal geblieben (nur `/healthz`,
|
||
`/internal/tenants`) — kein späteres Ticket (RBAC-02, CFG-02, API-06,
|
||
...) wurde je dort zentral eingehängt. Jedes Modul entstand auf einer
|
||
eigenen, unabhängigen Feature-Branch-Kette. API-11 folgt dem in dieser
|
||
Session etablierten Muster (RBAC-06, CFG-05, RET-09): ein eigener,
|
||
kleiner HTTP-Dienst statt eines zentralen `cmd/core`-Umbaus.
|
||
|
||
## Umsetzung
|
||
|
||
- `cmd/resync-api/main.go` – startet `internal/resync.Handler` mit
|
||
echten Produktions-Implementierungen: `moduleregistry.Registry`
|
||
(Auth), `audit.Log` (über `auditAdapter`), `usage.Store`.
|
||
- `deploy/systemd/nexarch-resync-api.service.tmpl`.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-resync-api.service` aktiv, `Restart=on-failure` |
|
||
| 2 | Realer POST /internal/resync/usage von einem externen Testclient gegen den laufenden Dienst liefert die erwartete Verarbeitung | **bestanden** – real per `curl`: mit echtem, über `moduleregistry.Registry.Provision` ausgestelltem Service-Credential (`X-Nexarch-Client-Id`/`X-Nexarch-Client-Secret`) liefert der Aufruf `{"applied":1}`, `usage_counters` zeigt real den erhöhten Zähler; mit falschem Credential 401. Testdaten (Modul, Credential, Zähler-Zeile) anschließend entfernt |
|
||
| 3 | Code-Review: keine Änderung an internal/resync/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: `internal/resync/`, `internal/audit/`, `internal/usage/`, `internal/moduleregistry/` unverändert gegenüber ihren jeweiligen Ticket-Ständen |
|
||
|
||
## Echte Verdrahtung auf 192.168.1.131
|
||
|
||
- `resync-api` gebaut nach `/opt/nexarch-core/bin/`,
|
||
`/etc/nexarch/resync-api.env` (0600), `nexarch-resync-api.service`
|
||
installiert/aktiviert.
|
||
- Reale Rechtevergabe-Lücke gefunden und behoben (gleiches Muster wie
|
||
bei den vorherigen Wrapper-Diensten): `modules`, `module_credentials`,
|
||
`audit_events`, `feature_flags`, `usage_counters`,
|
||
`resync_audit_buffer`, `resync_usage_buffer` gehörten `postgres`,
|
||
`nexarch_core` hatte keine Rechte — `GRANT` nachgezogen und über
|
||
`information_schema.role_table_grants` verifiziert, bevor der
|
||
End-zu-Ende-Test erneut lief.
|
||
- Zusätzliche reale Erkenntnis: `usage_counters.tenant_id` ist `UUID`,
|
||
nicht der Tenant-Slug (String) — beim ersten Testversuch mit `"acme"`
|
||
scheiterte der Insert intern, `UsageHandler` meldete `applied:0` statt
|
||
eines Fehlers (stiller Fehlschlag pro Delta, so von API-06 selbst so
|
||
entworfen: "Aufrufer entfernt aus seinem Puffer nur bestätigt
|
||
übernommene Deltas" — kein API-11-Defekt, sondern korrektes,
|
||
bestehendes API-06-Verhalten). Mit echter UUID als `tenant_slug`-Wert
|
||
lieferte der Aufruf real `applied:1`.
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./cmd/resync-api/... -> 0 issues
|
||
```
|
||
|
||
Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go/Adapter,
|
||
die eigentliche Logik ist bereits durch API-06s eigene Tests
|
||
abgedeckt).
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** API-06 ist jetzt ein real laufender, über systemd
|
||
verwalteter Dienst. Modul-Clients wie DMS' `storage.HTTPUsageReporter`
|
||
(RET-06/DOC-16-Umfeld) können sich jetzt real gegen einen laufenden
|
||
Endpunkt verdrahten, statt gegen unverdrahteten Go-Code zu testen.
|