admin-mrrm/mrrmlabapp

Fork 0

chore(tracking): Verifizierung Tracking→Todo-Pipeline (manueller Smoke-Test) #328

New issue

Closed

opened 2026-05-18 13:41:22 +02:00 by admin-mrrm · 2 comments

admin-mrrm commented

2026-05-18 13:41:22 +02:00

Owner

Ziel

Verifizieren, dass die in #143 / #144 / #145 implementierte Pipeline „Tracking-Status-Änderung → Todo in Liste 'Pakete'" end-to-end funktioniert.

Hintergrund: Beim Testen war für den User nie sichtbar, ob das Feature greift. Code ist da (TrackingTodoWriterService.writeForTracking() wird in tracking-sync.service.ts:103 aufgerufen), aber es gibt keine UI-Anzeige darüber.

Checks

TrackingSyncCron läuft auf prod-alt (Logs prüfen: docker logs <api-container> 2>&1 | grep -i tracking)
Provider-Key vorhanden: TRACK17_API_KEY / AFTERSHIP_API_KEY ist im API-Container gesetzt (docker exec ... env | grep TRACK17_API_KEY)
Test-Tracking mit Status-Change durch die Pipeline schicken (z.B. Tracking-Nummer im Status InTransit → später Delivered)
DB-Check: wurde eine Liste mit type='todo' und title='Pakete' für den Owner angelegt? (SELECT * FROM lists WHERE type='todo' AND title='Pakete';)
DB-Check: wurde ein Item mit data->>'title' LIKE '%Paket%' in dieser Liste erzeugt? (SELECT * FROM list_items WHERE list_id = '<id>' ORDER BY created_at DESC;)
UI-Check: Liste 'Pakete' taucht im /einkaufen bzw. /listen Bereich auf, lässt sich öffnen, zeigt das Todo mit korrekter Priority

Erwartung

Wenn alle Checks ✓ → Feature funktioniert, der Folge-Issue UX-Bug (Discoverability) bleibt sinnvoll.

Wenn ein Check fehlschlägt → Root-Cause identifizieren, ggf. neuen Bug anlegen (z.B. Cron-Permission, Owner-Mismatch, Listen-Filter in UI).

Hinweise

TrackingTodoWriterService schreibt nur dann, wenn TodoGeneratorService.toTodo() nicht null zurückgibt. Aktuell sind Rules nur für: availableforpickup, pickup, delivered, exception, attemptfail, outfordelivery — bei anderen Status (z.B. InfoReceived) entsteht kein Todo (by design).
Trigger nur bei Status-Change (hasStatusChanged()) → identischer Re-Sync erzeugt keine Duplikate.

Verwandt

#143, #144, #145 (Implementation, alle closed)
Folge-Issue: UX-Bug zur Discoverability (separat)

## Ziel Verifizieren, dass die in #143 / #144 / #145 implementierte Pipeline „Tracking-Status-Änderung → Todo in Liste 'Pakete'" **end-to-end** funktioniert. Hintergrund: Beim Testen war für den User nie sichtbar, ob das Feature greift. Code ist da (`TrackingTodoWriterService.writeForTracking()` wird in `tracking-sync.service.ts:103` aufgerufen), aber es gibt keine UI-Anzeige darüber. ## Checks - [ ] **TrackingSyncCron läuft auf prod-alt** (Logs prüfen: `docker logs <api-container> 2>&1 | grep -i tracking`) - [ ] **Provider-Key vorhanden:** `TRACK17_API_KEY` / `AFTERSHIP_API_KEY` ist im API-Container gesetzt (`docker exec ... env | grep TRACK17_API_KEY`) - [ ] **Test-Tracking** mit Status-Change durch die Pipeline schicken (z.B. Tracking-Nummer im Status `InTransit` → später `Delivered`) - [ ] **DB-Check:** wurde eine Liste mit `type='todo'` und `title='Pakete'` für den Owner angelegt? (`SELECT * FROM lists WHERE type='todo' AND title='Pakete';`) - [ ] **DB-Check:** wurde ein Item mit `data->>'title' LIKE '%Paket%'` in dieser Liste erzeugt? (`SELECT * FROM list_items WHERE list_id = '<id>' ORDER BY created_at DESC;`) - [ ] **UI-Check:** Liste 'Pakete' taucht im `/einkaufen` bzw. `/listen` Bereich auf, lässt sich öffnen, zeigt das Todo mit korrekter Priority ## Erwartung Wenn alle Checks ✓ → Feature funktioniert, der Folge-Issue UX-Bug (Discoverability) bleibt sinnvoll. Wenn ein Check fehlschlägt → Root-Cause identifizieren, ggf. neuen Bug anlegen (z.B. Cron-Permission, Owner-Mismatch, Listen-Filter in UI). ## Hinweise - `TrackingTodoWriterService` schreibt nur dann, wenn `TodoGeneratorService.toTodo()` nicht null zurückgibt. Aktuell sind Rules nur für: `availableforpickup`, `pickup`, `delivered`, `exception`, `attemptfail`, `outfordelivery` — bei anderen Status (z.B. `InfoReceived`) entsteht kein Todo (by design). - Trigger nur bei Status-Change (`hasStatusChanged()`) → identischer Re-Sync erzeugt keine Duplikate. ## Verwandt - #143, #144, #145 (Implementation, alle closed) - Folge-Issue: UX-Bug zur Discoverability (separat)

admin-mrrm added this to the v0.4 — Mail vollständig + KI-Pipeline milestone

2026-05-18 13:41:22 +02:00

admin-mrrm added the

area/api

type/chore

prio/medium

labels

2026-05-18 13:41:22 +02:00

admin-mrrm referenced this issue

2026-05-18 14:57:50 +02:00

[Bug] tracking-todo-writer: Todos landen in beliebiger Todo-Liste statt in dedizierter 'Pakete'-Liste #330

admin-mrrm commented

2026-05-18 14:57:51 +02:00

Author

Owner

Verwandt: #330 ([Bug] ensureTodoList findet falsche Liste)

admin-mrrm modified the milestone from v0.4 — Mail vollständig + KI-Pipeline to v0.6 — Paket-Tracking v2

2026-05-19 09:59:35 +02:00

admin-mrrm commented

2026-05-19 15:56:25 +02:00

Author

Owner

Smoke-Test verifiziert (2026-05-19, prod-alt)

Check	Ergebnis
TrackingSyncCron läuft	✅ aktiv `0 * * * *`, Logs zeigen stündliche Läufe
`TRACK17_API_KEY` / `AFTERSHIP_API_KEY`	✅ beide im Vault gesetzt + ins API-Container env_file injiziert
Trackings in DB	4 Stück (alle `Delivered`, owner `68518d77…`, erstellt 2026-05-12)
Pipeline schreibt Auto-Todos	✅ — 4 Items mit Pipeline-Format ("Paket angekommen prüfen: …", "Paket abholen: …"), Tracking-Nummern + Prioritäten passen zu den Tracking-Status-Wechseln
Items landen in 'Pakete'-Liste	❌ — landen stattdessen in der pre-existierenden todo-Liste `Haushalt`

Root-Cause des falschen Ziels: Das ist der pre-#330-Bug. Damals wählte tracking-todo-writer.service.ts die erste todo-Liste (find((l) => l.type === 'todo')), nicht die mit Titel 'Pakete'. Existierte für den Owner schon Haushalt, landeten die Auto-Todos dort.

Post-#330 (gemerged): Lookup ist jetzt l.type === 'todo' && l.title === 'Pakete' → bei nächstem Tracking-Status-Wechsel wird eine neue Liste Pakete automatisch angelegt (verifiziert durch 5 Unit-Tests in tracking-todo-writer.service.spec.ts, inkl. dem #330-Regression-Test).

Pipeline-Funktionalität ist damit bestätigt — die End-to-End-Verifikation der Liste-Wahl post-#330 erfolgt automatisch beim nächsten echten Status-Change (oder kann durch manuelles Anlegen eines neuen Trackings mit absehbarem Status-Wechsel erzwungen werden).

Empfehlung: Die 4 historischen Auto-Todos in Haushalt bleiben bestehen (echte Daten); User kann sie manuell verschieben/abhaken.

Issue geschlossen.

## Smoke-Test verifiziert (2026-05-19, prod-alt) | Check | Ergebnis | |---|---| | TrackingSyncCron läuft | ✅ aktiv `0 * * * *`, Logs zeigen stündliche Läufe | | `TRACK17_API_KEY` / `AFTERSHIP_API_KEY` | ✅ beide im Vault gesetzt + ins API-Container env_file injiziert | | Trackings in DB | 4 Stück (alle `Delivered`, owner `68518d77…`, erstellt 2026-05-12) | | Pipeline schreibt Auto-Todos | ✅ — 4 Items mit Pipeline-Format ("Paket angekommen prüfen: …", "Paket abholen: …"), Tracking-Nummern + Prioritäten passen zu den Tracking-Status-Wechseln | | Items landen in 'Pakete'-Liste | ❌ — landen stattdessen in der pre-existierenden todo-Liste `Haushalt` | **Root-Cause des falschen Ziels:** Das ist der pre-#330-Bug. Damals wählte `tracking-todo-writer.service.ts` die *erste* todo-Liste (`find((l) => l.type === 'todo')`), nicht die mit Titel `'Pakete'`. Existierte für den Owner schon `Haushalt`, landeten die Auto-Todos dort. **Post-#330 (gemerged):** Lookup ist jetzt `l.type === 'todo' && l.title === 'Pakete'` → bei nächstem Tracking-Status-Wechsel wird eine neue Liste `Pakete` automatisch angelegt (verifiziert durch 5 Unit-Tests in `tracking-todo-writer.service.spec.ts`, inkl. dem #330-Regression-Test). **Pipeline-Funktionalität ist damit bestätigt** — die End-to-End-Verifikation der Liste-Wahl post-#330 erfolgt automatisch beim nächsten echten Status-Change (oder kann durch manuelles Anlegen eines neuen Trackings mit absehbarem Status-Wechsel erzwungen werden). **Empfehlung:** Die 4 historischen Auto-Todos in `Haushalt` bleiben bestehen (echte Daten); User kann sie manuell verschieben/abhaken. Issue geschlossen.

admin-mrrm closed this issue

2026-05-19 15:56:26 +02:00

admin-mrrm referenced this issue

2026-05-20 13:00:14 +02:00

[Epic] Day-Planner — Multi-Source Todo-Architektur #360