AC1-3 real gegen echte workflow-app-Instanz getestet.
Bug in anderem Modul gefunden (nicht dort gefixt, Umbau angrenzender Bereiche vermieden): workflow/internal/moduleadapter PublishEvent verwendet NULLIF($7, '') fuer dedupe_key, Spalte ist aber NOT NULL DEFAULT '' - leerer dedupe_key (dokumentierter Default-Fall) schlaegt serverseitig mit Constraint-Verletzung fehl. Workaround mail-seitig: immer abgeleiteter, nicht-leerer dedupe_key. Siehe Pruefprotokoll.
Offen (dokumentiert, ausserhalb Scope): kein konkreter SMTP/Hotfolder-Call-Site zum automatischen Ausloesen von PublishMailReceived bei tatsaechlicher Zustellung (smtp.MessageSink/hotfolder.Handler sind noch Interfaces, wie bei DMS INT-13).
mail/internal/workflowevent registriert message/thread Objekttypen + Ausloeser (mail.received, mail.delivery_failed, mail.deadline_reached) gegen Workflow ENG-02, asynchrone Postgres-Jobqueue (analog internal/webhook, dms/internal/workflowevent INT-13).
AC1-3 real gegen echte workflow-app-Instanz getestet.
Bug in anderem Modul gefunden (nicht dort gefixt, Umbau angrenzender Bereiche vermieden): workflow/internal/moduleadapter PublishEvent verwendet NULLIF($7, '') fuer dedupe_key, Spalte ist aber NOT NULL DEFAULT '' - leerer dedupe_key (dokumentierter Default-Fall) schlaegt serverseitig mit Constraint-Verletzung fehl. Workaround mail-seitig: immer abgeleiteter, nicht-leerer dedupe_key. Siehe Pruefprotokoll.
Offen (dokumentiert, ausserhalb Scope): kein konkreter SMTP/Hotfolder-Call-Site zum automatischen Ausloesen von PublishMailReceived bei tatsaechlicher Zustellung (smtp.MessageSink/hotfolder.Handler sind noch Interfaces, wie bei DMS INT-13).
Siehe mail/docs/INT-10-PRUEFPROTOKOLL.md.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
patrick
added 3 commits 2026-10-16 08:49:53 +02:00
Mail-Objekttypen message/thread samt Ausloeser-Ereignissen (mail.received,
mail.delivery_failed, mail.deadline_reached) ueber den ENG-02-Adapter bei
Workflow registrierbar (RegisterAll). Ereignis-Publikation laeuft ueber
eine eigene Postgres-Jobqueue (mail_workflow_events, FOR UPDATE SKIP
LOCKED) analog zu internal/webhook (Core) und mail/internal/indexworker:
Publisher.Publish* reiht nur ein (kein HTTP-Aufruf im Anfragepfad),
Dispatcher stellt im Hintergrund zu und macht Fehlschlaege per
last_error/Retry-Backoff sichtbar statt sie zu verwerfen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Je Akzeptanzkriterium ein automatisierter Test, real gegen Postgres
(TEST_TENANT_DSN) UND gegen eine echte, als Subprozess gestartete
workflow-app (workflow/cmd/workflow-app) -- kein HTTP-Fake, da Mail und
Workflow als getrennte Go-Module ausschliesslich ueber den echten
ENG-02-Adapter gekoppelt sind:
- RegisterAll traegt message/thread samt Triggern tatsaechlich in
module_registrations/module_registration_versions der laufenden
Workflow-Instanz ein, auch bei wiederholtem Aufruf (Dienst-Neustart).
- PublishMailReceived + Dispatcher.RunOnce liefern mail.received
nachweisbar in module_events der echten Instanz aus.
- Ein nicht erreichbarer Workflow-Endpunkt blockiert Enqueue nicht und
hinterlaesst last_error/Status pending statt das Ereignis zu
verwerfen.
Dabei Fehler im ENG-02-Adapter gefunden und umgangen (nicht am Adapter
selbst behoben, anderes Modul/Board): PublishEvent setzt einen leeren
dedupe_key per NULLIF auf NULL, die Spalte ist aber NOT NULL -- jede
Zustellung ohne Dedup-Schluessel schlug serverseitig fehl. Mail liefert
deshalb immer einen abgeleiteten dedupe_key (mail:{object_type}:{trigger}:{object_id})
statt sich auf einen leeren Schluessel zu verlassen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zielwerte und Ergebnisse aller drei Pflichtpruefungen dokumentiert,
inklusive des gefundenen dedupe_key-NOT-NULL-Fehlers im ENG-02-Adapter
(dort nicht behoben, nur in Mail umgangen) und der bewusst offenen
Verdrahtung in einen konkreten SMTP-/Hotfolder-Zustellpfad.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mail/internal/workflowevent registriert message/thread Objekttypen + Ausloeser (mail.received, mail.delivery_failed, mail.deadline_reached) gegen Workflow ENG-02, asynchrone Postgres-Jobqueue (analog internal/webhook, dms/internal/workflowevent INT-13).
AC1-3 real gegen echte workflow-app-Instanz getestet.
Bug in anderem Modul gefunden (nicht dort gefixt, Umbau angrenzender Bereiche vermieden): workflow/internal/moduleadapter PublishEvent verwendet NULLIF($7, '') fuer dedupe_key, Spalte ist aber NOT NULL DEFAULT '' - leerer dedupe_key (dokumentierter Default-Fall) schlaegt serverseitig mit Constraint-Verletzung fehl. Workaround mail-seitig: immer abgeleiteter, nicht-leerer dedupe_key. Siehe Pruefprotokoll.
Offen (dokumentiert, ausserhalb Scope): kein konkreter SMTP/Hotfolder-Call-Site zum automatischen Ausloesen von PublishMailReceived bei tatsaechlicher Zustellung (smtp.MessageSink/hotfolder.Handler sind noch Interfaces, wie bei DMS INT-13).
Siehe mail/docs/INT-10-PRUEFPROTOKOLL.md.
🤖 Generated with Claude Code
Je Akzeptanzkriterium ein automatisierter Test, real gegen Postgres (TEST_TENANT_DSN) UND gegen eine echte, als Subprozess gestartete workflow-app (workflow/cmd/workflow-app) -- kein HTTP-Fake, da Mail und Workflow als getrennte Go-Module ausschliesslich ueber den echten ENG-02-Adapter gekoppelt sind: - RegisterAll traegt message/thread samt Triggern tatsaechlich in module_registrations/module_registration_versions der laufenden Workflow-Instanz ein, auch bei wiederholtem Aufruf (Dienst-Neustart). - PublishMailReceived + Dispatcher.RunOnce liefern mail.received nachweisbar in module_events der echten Instanz aus. - Ein nicht erreichbarer Workflow-Endpunkt blockiert Enqueue nicht und hinterlaesst last_error/Status pending statt das Ereignis zu verwerfen. Dabei Fehler im ENG-02-Adapter gefunden und umgangen (nicht am Adapter selbst behoben, anderes Modul/Board): PublishEvent setzt einen leeren dedupe_key per NULLIF auf NULL, die Spalte ist aber NOT NULL -- jede Zustellung ohne Dedup-Schluessel schlug serverseitig fehl. Mail liefert deshalb immer einen abgeleiteten dedupe_key (mail:{object_type}:{trigger}:{object_id}) statt sich auf einen leeren Schluessel zu verlassen. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Inhalt bereits in main enthalten (geprueft per merge_all_prs.sh: leerer Merge-Diff). Geschlossen ohne Merge.
Pull request closed