Files

T

sysops d6e9412043 API-11: wiederanlauf-nachsynchronisierungs-endpunkt-starten

- 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

2026-08-30 20:14:07 +02:00

4.0 KiB

Raw Blame History

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.

4.0 KiB Raw Blame History Unescape Escape