feat: Webhook-Warteschlange in Datenbank persistieren
Build and Push Multi-Platform Images / build-and-push (push) Successful in 31s
Build and Push Multi-Platform Images / build-and-push (push) Successful in 31s
Die Warteschlange liegt nicht mehr im Speicher, sondern in der neuen Tabelle webhook_queue (Entity WebhookQueueItem, documentId als Primärschlüssel). So überstehen ausstehende IDs einen Neustart und werden nach dem Boot weiterverarbeitet. - Neue Entity + Migration (CreateWebhookQueue); in data-source.ts/Barrel registriert. Dev: synchronize legt die Tabelle an; Prod: migrationsRun. - enqueue nutzt INSERT IGNORE (atomar, race-sicher) -> Dedup über den PK. - processQueue holt FIFO (createdAt ASC), entfernt die Zeile vor der Verarbeitung, arbeitet sequenziell (isProcessing-Guard). - getStatus/queueSize lesen die DB-Anzahl. Controller awaitet enqueue. - Unit-Test mit simuliertem FIFO-Repo: Dedup, Remove-on-start, Re-Enqueue, No-Parallel (deterministisch). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -26,6 +26,7 @@ import {
|
||||
CorrespondentEmailMapping,
|
||||
UserSettings,
|
||||
LabelPrintJob,
|
||||
WebhookQueueItem,
|
||||
} from './entities';
|
||||
|
||||
// CLI-Kontext: .env laden (Laufzeit im Container liefert die Variablen via Docker,
|
||||
@@ -57,6 +58,7 @@ export const entities = [
|
||||
CorrespondentEmailMapping,
|
||||
UserSettings,
|
||||
LabelPrintJob,
|
||||
WebhookQueueItem,
|
||||
];
|
||||
|
||||
const isProduction = process.env.NODE_ENV === 'production';
|
||||
|
||||
Reference in New Issue
Block a user