sysopsandClaude Sonnet 5
b6184b67aa
internal/usage/storage.go: ReportStorageWrite/ReportStorageDelete sind duenne Spezialisierungen von LIC-03s bereits atomarem Store.Increment auf die feste Metrik "storage_bytes" — Loeschung nutzt einfach ein negatives Delta desselben UPSERT-Mechanismus, kein zweiter Zaehl-Codepfad. Damit uebernehmen Akzeptanzkriterium 2 (atomar, race-frei) und die zugehoerigen LIC-03-Garantien direkt, ohne Duplikat. CurrentStorageUsage ist ein einfaches Store.Get auf dieselbe Metrik — LIC-03 kann denselben Wert ueber Store.Get(tenant, StorageBytesMetric) abfragen (Akzeptanzkriterium 3, per Test TestCurrentStorageUsage_MatchesGenericStoreGet belegt: kein zweiter, abweichender Zaehlmechanismus). Die Objekt-Storage-Treiber der Module (DMS FDN-03, Mail ARC-01), die diese Funktionen bei jedem Schreib-/Loeschvorgang aufrufen wuerden, existieren als Code noch nicht (nur geplant in dms-kanban/mail-kanban) — diese Kachel implementiert nur die Core-seitige Zaehl-Schnittstelle, analog zum AUD-05/RetentionRegistrar-Muster. Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Paralleler Schreib-Test (viele gleichzeitige Uploads) ergibt korrekten Endstand ohne verlorene Updates — TestReportStorageWrite_ConcurrentUploadsSumCorrectly: 10 parallele Schreibvorgaenge unterschiedlicher Groesse, Endstand exakt gleich der in Go unabhaengig berechneten Summe. PASS. 2. Loeschvorgang dekrementiert korrekt — TestReportStorageDelete_Decrements. PASS. 3. Abfrage liefert konsistenten Wert mit unabhaengiger Kontrollzaehlung — TestCurrentStorageUsage_MatchesIndependentTally (gemischte Schreib-/ Loeschfolge, in Go parallel mitgezaehlt) und TestCurrentStorageUsage_MatchesGenericStoreGet. PASS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
48 lines
1.9 KiB
Go
48 lines
1.9 KiB
Go
package usage
|
|
|
|
import (
|
|
"context"
|
|
"errors"
|
|
"fmt"
|
|
)
|
|
|
|
// StorageBytesMetric ist der feste Metrikname, unter dem der belegte
|
|
// Speicherplatz je Tenant gefuehrt wird (LIC-05, siehe
|
|
// core-kanban/tickets/LIC-05.md). LIC-03 fragt genau diese Metrik ueber
|
|
// Store.Get/Store.Check ab — kein zweiter, paralleler Speicher-Zaehler.
|
|
const StorageBytesMetric = "storage_bytes"
|
|
|
|
// ReportStorageWrite wird von den Objekt-Storage-Treibern der Module (DMS
|
|
// FDN-03, Mail ARC-01 — existieren als Code noch nicht) bei jedem
|
|
// Schreibvorgang aufgerufen. Nutzt Store.Increment, das bereits atomar ist
|
|
// (Akzeptanzkriterium 2, siehe LIC-03) — kein zweiter Inkrement-Mechanismus
|
|
// nur fuer Speicher.
|
|
func (s *Store) ReportStorageWrite(ctx context.Context, tenantID string, sizeBytes int64) error {
|
|
if sizeBytes < 0 {
|
|
return errors.New("usage: sizeBytes darf bei einem schreibvorgang nicht negativ sein")
|
|
}
|
|
if err := s.Increment(ctx, tenantID, StorageBytesMetric, sizeBytes); err != nil {
|
|
return fmt.Errorf("speicherverbrauch (schreiben) melden: %w", err)
|
|
}
|
|
return nil
|
|
}
|
|
|
|
// ReportStorageDelete wird bei jedem Loeschvorgang aufgerufen — dekrementiert
|
|
// denselben Zaehler ueber ein negatives Delta desselben atomaren UPSERT.
|
|
func (s *Store) ReportStorageDelete(ctx context.Context, tenantID string, sizeBytes int64) error {
|
|
if sizeBytes < 0 {
|
|
return errors.New("usage: sizeBytes darf bei einem loeschvorgang nicht negativ sein")
|
|
}
|
|
if err := s.Increment(ctx, tenantID, StorageBytesMetric, -sizeBytes); err != nil {
|
|
return fmt.Errorf("speicherverbrauch (loeschen) melden: %w", err)
|
|
}
|
|
return nil
|
|
}
|
|
|
|
// CurrentStorageUsage liefert den aktuellen Speicherverbrauch eines Tenants
|
|
// (Akzeptanzkriterium 3) — ein einfaches Get auf den bereits gefuehrten
|
|
// Zaehler, kein Scan des Objekt-Storage.
|
|
func (s *Store) CurrentStorageUsage(ctx context.Context, tenantID string) (int64, error) {
|
|
return s.Get(ctx, tenantID, StorageBytesMetric)
|
|
}
|