fix: Apilo email z danymi zamówienia + infinite retry co 30 min dla order jobów

- Email notyfikacji zawiera numer zamówienia, klienta, datę, kwotę - Order joby (send_order, sync_payment, sync_status) ponawiane w nieskończoność co 30 min - Rozróżnienie PONAWIANY vs TRWAŁY BŁĄD w emailu - Cleanup stuck jobów po udanym wysłaniu zamówienia - +2 testy infinite retry w CronJobRepositoryTest Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-19 11:23:02 +01:00
parent 4cda46d4bc
commit 72864d18ba
12 changed files with 476 additions and 27 deletions
--- a/.paul/ROADMAP.md
+++ b/.paul/ROADMAP.md
@@ -35,6 +35,7 @@ Status: Planning
 |-------|------|-------|--------|-----------|
 | 7 | Coupon Fatal Error — order placement crash | 1 | Done | 2026-03-15 |
 | 8 | Apilo orders not sending — diagnoza i naprawa | 1 | Done | 2026-03-16 |
+| 9 | Apilo email notification + infinite retry | 1 | Done | 2026-03-19 |

 ## Phase Details

@@ -66,4 +67,4 @@ Status: Planning

 ---
 *Roadmap created: 2026-03-12*
-*Last updated: 2026-03-16*
+*Last updated: 2026-03-19*
--- a/.paul/STATE.md
+++ b/.paul/STATE.md
@@ -5,25 +5,25 @@
 See: .paul/PROJECT.md (updated 2026-03-12)

 **Core value:** Właściciel sklepu ma pełną kontrolę nad sprzedażą online w jednym systemie pisanym od podstaw, bez narzutów zewnętrznych platform.
-**Current focus:** Hotfix Apilo — COMPLETE
+**Current focus:** Phase 9 complete — Apilo email fix + infinite retry

 ## Current Position

-Milestone: Hotfix — Apilo orders not sending
-Phase: 8 — Diagnoza i naprawa wysyłki zamówień do Apilo — Complete
-Plan: 08-01 complete (phase done)
-Status: UNIFY complete, phase 8 finished
-Last activity: 2026-03-16 — 08-01 UNIFY complete
+Milestone: Hotfix
+Phase: 9 — Apilo email notification + infinite retry — Complete
+Plan: 09-01 complete (phase done)
+Status: UNIFY complete, phase 9 finished
+Last activity: 2026-03-19 — 09-01 UNIFY complete

 Progress:
- Phase 8: [██████████] 100% (COMPLETE)
+- Phase 9: [██████████] 100% (COMPLETE)

 ## Loop Position

-Current loop state (phase 8, plan 01):
+Current loop state (phase 9, plan 01):
 ```
 PLAN ──▶ APPLY ──▶ UNIFY
-  ✓        ✓        ✓     [Phase 8 complete]
+  ✓        ✓        ✓     [Phase 9 complete]
 ```

 Previous phases:
@@ -33,6 +33,7 @@ Phase 5: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-0
 Phase 6: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-03-12]
 Phase 7: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-03-15]
 Phase 8: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-03-16]
+Phase 9: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-03-19]
 ```

 ## Accumulated Context
@@ -42,6 +43,9 @@ Phase 8: PLAN ──▶ APPLY ──▶ UNIFY  ✓ ✓ ✓  [COMPLETE — 2026-0
 - 2026-03-16: Przyczyna braku wysyłki = brakujące $apiloRepository w use() closures cron.php (regresja z fazy 6)
 - 2026-03-16: Retry -1 orders co 1h zamiast permanent failure
 - 2026-03-16: Email notification o trwale failed Apilo jobach
+- 2026-03-19: Order-related Apilo joby — infinite retry co 30 min (nigdy permanent failure)
+- 2026-03-19: Email z danymi zamówienia + rozróżnienie PONAWIANY vs TRWAŁY BŁĄD
+- 2026-03-19: Cleanup stuck sync_payment/sync_status jobów po udanym wysłaniu

 ### Deferred Issues
 None.
@@ -51,10 +55,10 @@ None.

 ## Session Continuity

-Last session: 2026-03-16
-Stopped at: Phase 08 UNIFY complete — Apilo fix loop closed
-Next action: Deploy fix to instance, then /paul:progress for next work
-Resume file: .paul/phases/08-apilo-orders-fix/08-01-SUMMARY.md
+Last session: 2026-03-19
+Stopped at: Phase 09 UNIFY complete
+Next action: Deploy fix or /paul:progress for next work
+Resume file: .paul/phases/09-apilo-email-fix/09-01-SUMMARY.md

 ---
 *STATE.md — Updated after every significant action*
--- a/.paul/phases/09-apilo-email-fix/09-01-PLAN.md
+++ b/.paul/phases/09-apilo-email-fix/09-01-PLAN.md
@@ -0,0 +1,201 @@
+---
+phase: 09-apilo-email-fix
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified: [cron.php, autoload/Domain/CronJob/CronJobRepository.php, autoload/Domain/CronJob/CronJobType.php]
+autonomous: true
+---
+
+<objective>
+## Goal
+1. Wzbogacić email notyfikacji o trwałym błędzie Apilo o czytelne dane zamówienia (numer, klient, kwota)
+2. Zamówienia Apilo (send_order, sync_payment, sync_status) muszą być ponawiane w nieskończoność co 30 minut
+3. Email o błędzie nadal wysyłany (jako ostrzeżenie), ale job wraca do pending zamiast permanent failure
+4. Po udanym wysłaniu zamówienia — czyścimy powiązane failed/pending joby
+
+## Purpose
+Administrator dostaje email bez informacji o którym zamówieniu chodzi. Dodatkowo, po 10 próbach zamówienie przestaje być synchronizowane — to niedopuszczalne, bo zamówienie musi trafić do Apilo.
+
+## Output
+- Zmodyfikowany `cron.php` — lepsza treść emaila + czyszczenie jobów po sukcesie
+- Zmodyfikowany `CronJobRepository` — obsługa infinite retry
+- Zmodyfikowany `CronJobType` — stała backoffu 30min dla Apilo
+</objective>
+
+<context>
+## Project Context
+@.paul/PROJECT.md
+@.paul/ROADMAP.md
+
+## Prior Work
+@.paul/phases/08-apilo-orders-fix/08-01-SUMMARY.md
+
+## Source Files
+@cron.php (linie 198-529 — handler APILO_SEND_ORDER, linie 763-781 — email notification)
+@autoload/Domain/CronJob/CronJobRepository.php (markFailed — linie 131-156)
+@autoload/Domain/CronJob/CronJobType.php (stałe backoff)
+</context>
+
+<acceptance_criteria>
+
+## AC-1: Email zawiera czytelne dane zamówienia
+```gherkin
+Given trwale nieudane zadanie Apilo z payload zawierającym order_id
+When system wysyła email notyfikacji
+Then email zawiera: numer zamówienia, dane klienta, datę zamówienia, kwotę
+  And temat emaila zawiera numery zamówień
+```
+
+## AC-2: Brak order_id w payload nie powoduje błędu
+```gherkin
+Given trwale nieudane zadanie Apilo bez order_id w payload (np. apilo_token_keepalive)
+When system wysyła email notyfikacji
+Then email wyświetla dane job-a bez sekcji zamówienia, bez błędów
+```
+
+## AC-3: Joby zamówień Apilo ponawiają się w nieskończoność co 30 minut
+```gherkin
+Given job typu apilo_send_order, apilo_sync_payment lub apilo_sync_status
+When job osiąga max_attempts
+Then job NIE jest oznaczany jako failed
+  And job wraca do pending ze scheduled_at = now + 30 minut
+  And email ostrzegawczy jest wysyłany (z informacją że job dalej jest ponawiany)
+```
+
+## AC-4: Inne joby Apilo (token, product sync) nadal mają limit prób
+```gherkin
+Given job typu apilo_token_keepalive lub apilo_product_sync
+When job osiąga max_attempts
+Then job jest oznaczany jako failed (zachowanie bez zmian)
+```
+
+## AC-5: Po udanym wysłaniu zamówienia czyszczone są powiązane failed joby
+```gherkin
+Given zamówienie wysłane pomyślnie do Apilo (apilo_order_id ustawiony)
+When handler APILO_SEND_ORDER kończy się sukcesem
+Then powiązane joby apilo_sync_payment i apilo_sync_status ze statusem failed
+  zostają usunięte lub anulowane (żeby nie zaśmiecały kolejki)
+```
+
+</acceptance_criteria>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Infinite retry dla order-related Apilo jobów</name>
+  <files>autoload/Domain/CronJob/CronJobType.php, autoload/Domain/CronJob/CronJobRepository.php</files>
+  <action>
+    **CronJobType.php:**
+    1. Dodać stałą `APILO_ORDER_BACKOFF_SECONDS = 1800` (30 minut)
+    2. Dodać statyczną metodę `isOrderRelatedApiloJob($jobType)` zwracającą true dla:
+       - APILO_SEND_ORDER, APILO_SYNC_PAYMENT, APILO_SYNC_STATUS
+
+    **CronJobRepository::markFailed():**
+    3. Przed sprawdzeniem `$attempts >= $maxAttempts`:
+       - Pobrać `job_type` z bazy (dodać do selecta w linia 133)
+       - Jeśli `CronJobType::isOrderRelatedApiloJob($jobType)`:
+         - ZAWSZE wracaj do pending (nigdy failed)
+         - Użyj stałego backoffu `APILO_ORDER_BACKOFF_SECONDS` zamiast exponential
+         - Ustaw `last_error` jak normalnie
+       - Dla pozostałych jobów — logika bez zmian
+
+    UWAGA: Nie zmieniaj sygnatury markFailed() — dodaj job_type do wewnętrznego selecta
+  </action>
+  <verify>
+    1. Przeczytaj kod i zweryfikuj że:
+       - isOrderRelatedApiloJob zwraca true tylko dla 3 typów
+       - markFailed nigdy nie ustawia status=failed dla tych typów
+       - Inne joby zachowują się jak dotychczas
+    2. Uruchom: ./test.ps1 tests/Unit/Domain/CronJob/
+  </verify>
+  <done>AC-3, AC-4 satisfied: Order joby retry w nieskończoność, inne bez zmian</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Lepszy email + ostrzeżenie zamiast trwałego błędu + czyszczenie po sukcesie</name>
+  <files>cron.php</files>
+  <action>
+    **Email notification (linie ~763-781):**
+    1. Zmienić query o failed joby — RÓWNIEŻ szukać order-related jobów w statusie pending z dużą liczbą prób (np. attempts >= 10), żeby wysyłać ostrzeżenie
+    2. Dla każdego job-a: sparsować payload (json_decode jeśli string), wyciągnąć order_id
+    3. Jeśli order_id istnieje — pobrać z pp_shop_orders:
+       - `order_number` (lub `id` jeśli brak), `client_name`/`client_surname`, `date_order`, `total_brutto`
+    4. Sformatować email:
+       ```
+       Job #X (apilo_send_order) — PONAWIANY CO 30 MIN
+         Zamówienie: #12345 (ID: 678)
+         Klient: Jan Kowalski
+         Data zamówienia: 2026-03-19 14:30:00
+         Kwota: 199.99 PLN
+         Próby: 15
+         Błąd: [last_error]
+         Ostatnia próba: [updated_at lub scheduled_at]
+       ```
+    5. Dla jobów permanent failed (nie-order): zachować stary format "trwały błąd"
+    6. Temat: dodać numery zamówień jeśli dostępne
+    7. Email ma rozróżniać: "PONAWIANY" vs "TRWAŁY BŁĄD" w zależności od typu joba
+
+    **Czyszczenie po sukcesie (w handlerze APILO_SEND_ORDER, po linii ~522-524):**
+    8. Po pomyślnym wysłaniu zamówienia (`apilo_order_id` ustawiony):
+       - Usunąć/anulować failed/pending joby `apilo_sync_payment` i `apilo_sync_status`
+         z payload zawierającym ten sam order_id
+       - Użyć: `$mdb->delete('pp_cron_jobs', [...])` lub update status=cancelled
+       - To zapobiega zaśmiecaniu kolejki starymi retry jobami
+
+    UWAGA:
+    - Nazwy kolumn zamówienia: sprawdź jakie faktycznie są w pp_shop_orders (mogą być polskie)
+    - Payload w bazie to JSON string — json_decode($fj['payload'], true)
+    - Nie zmieniaj logiki wysyłania zamówień — tylko email i cleanup
+  </action>
+  <verify>
+    1. Przeczytaj zmodyfikowany kod
+    2. Zweryfikuj że query do pp_shop_orders używa poprawnych kolumn
+    3. Zweryfikuj brak błędów PHP (null handling, json_decode guard)
+    4. Uruchom: ./test.ps1
+  </verify>
+  <done>AC-1, AC-2, AC-5 satisfied: Email czytelny, cleanup po sukcesie</done>
+</task>
+
+</tasks>
+
+<boundaries>
+
+## DO NOT CHANGE
+- Logikę wysyłania zamówień do Apilo (curl, payload budowanie)
+- Logikę exponential backoff dla NIE-order jobów
+- Handlery APILO_SYNC_PAYMENT, APILO_SYNC_STATUS, APILO_STATUS_POLL (poza cleanup)
+- Odbiorcę emaila i warunki wysyłki (poza rozszerzeniem query)
+- Tabelę pp_shop_orders — żadnych nowych kolumn
+
+## SCOPE LIMITS
+- Tylko retry logic, email formatting, i cleanup
+- Nie dodawać nowych tabel
+- Nie zmieniać enqueue() ani fetchNext()
+
+</boundaries>
+
+<verification>
+Before declaring plan complete:
+- [ ] Order-related Apilo joby nigdy nie dostają status=failed
+- [ ] Backoff dla order jobów = stałe 30 min
+- [ ] Inne joby zachowują stare zachowanie (exponential, max 10)
+- [ ] Email zawiera numer zamówienia gdy dostępny
+- [ ] Email rozróżnia "ponawiany" vs "trwały błąd"
+- [ ] Po sukcesie wysyłki czyścimy related joby
+- [ ] Brak błędów PHP
+- [ ] Testy przechodzą (./test.ps1)
+- [ ] All acceptance criteria met
+</verification>
+
+<success_criteria>
+- Zamówienia Apilo są ponawiane w nieskończoność co 30 min
+- Email notyfikacji zawiera czytelne dane zamówienia
+- Po udanym wysłaniu czyszczone są stare joby
+- Zero regresji w testach
+</success_criteria>
+
+<output>
+After completion, create `.paul/phases/09-apilo-email-fix/09-01-SUMMARY.md`
+</output>
--- a/.paul/phases/09-apilo-email-fix/09-01-SUMMARY.md
+++ b/.paul/phases/09-apilo-email-fix/09-01-SUMMARY.md
@@ -0,0 +1,111 @@
+---
+phase: 09-apilo-email-fix
+plan: 01
+subsystem: integrations
+tags: [apilo, cron, email, retry]
+
+requires:
+  - phase: 08-apilo-orders-fix
+    provides: cron job system, Apilo email notification
+provides:
+  - Infinite retry dla order-related Apilo jobów (30 min interval)
+  - Email notyfikacji z danymi zamówienia (numer, klient, kwota)
+  - Cleanup starych jobów po udanym wysłaniu
+affects: []
+
+tech-stack:
+  added: []
+  patterns:
+    - "isOrderRelatedApiloJob() — centralna identyfikacja order jobów Apilo"
+    - "Infinite retry pattern — stały backoff zamiast exponential dla krytycznych jobów"
+
+key-files:
+  modified:
+    - autoload/Domain/CronJob/CronJobType.php
+    - autoload/Domain/CronJob/CronJobRepository.php
+    - cron.php
+
+key-decisions:
+  - "Order joby Apilo nigdy nie failują trwale — infinite retry co 30 min"
+  - "Email rozróżnia PONAWIANY vs TRWAŁY BŁĄD"
+  - "Po udanym wysłaniu zamówienia czyszczone są stuck joby sync_payment/sync_status"
+
+duration: ~15min
+completed: 2026-03-19
+---
+
+# Phase 9 Plan 01: Apilo email fix + infinite retry — Summary
+
+**Email notyfikacji Apilo wzbogacony o dane zamówienia (numer, klient, kwota) + order joby ponawiane w nieskończoność co 30 min zamiast permanent failure po 10 próbach.**
+
+## Performance
+
+| Metric | Value |
+|--------|-------|
+| Duration | ~15 min |
+| Completed | 2026-03-19 |
+| Tasks | 2 completed |
+| Files modified | 4 (+ 1 test file) |
+| Tests | 820 passed, 2277 assertions |
+
+## Acceptance Criteria Results
+
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| AC-1: Email zawiera dane zamówienia | Pass | Numer, klient, data, kwota z pp_shop_orders |
+| AC-2: Brak order_id nie powoduje błędu | Pass | Graceful handling — pokazuje tylko dane joba |
+| AC-3: Order joby retry co 30 min w nieskończoność | Pass | isOrderRelatedApiloJob() + stały backoff 1800s |
+| AC-4: Inne joby zachowują limit prób | Pass | Testy potwierdzają — price_history nadal failuje po max_attempts |
+| AC-5: Cleanup po udanym wysłaniu | Pass | delete stuck sync_payment/sync_status jobów |
+
+## Accomplishments
+
+- Order-related Apilo joby (send_order, sync_payment, sync_status) nigdy nie wpadają w permanent failure — zawsze wracają do pending co 30 min
+- Email notyfikacji zawiera czytelne dane zamówienia zamiast surowego JSON payload
+- Temat emaila zawiera numery zamówień dla szybkiej identyfikacji
+- Email rozróżnia "PONAWIANY CO 30 MIN" vs "TRWAŁY BŁĄD" w zależności od typu joba
+- Po udanym wysłaniu zamówienia do Apilo czyszczone są stare stuck joby sync_payment/sync_status
+
+## Files Created/Modified
+
+| File | Change | Purpose |
+|------|--------|---------|
+| `autoload/Domain/CronJob/CronJobType.php` | Modified | +APILO_ORDER_BACKOFF_SECONDS (1800s), +isOrderRelatedApiloJob() |
+| `autoload/Domain/CronJob/CronJobRepository.php` | Modified | markFailed() — infinite retry dla order jobów |
+| `cron.php` | Modified | Email z danymi zamówienia + cleanup po sukcesie |
+| `tests/Unit/Domain/CronJob/CronJobRepositoryTest.php` | Modified | +2 testy infinite retry, fix mocków z job_type |
+
+## Decisions Made
+
+| Decision | Rationale | Impact |
+|----------|-----------|--------|
+| Stały backoff 1800s zamiast exponential | Zamówienia muszą trafić do Apilo — przewidywalny interwał ważniejszy niż agresywny retry | Order joby ponawiane regularnie co 30 min |
+| Email ostrzegawczy zamiast "trwały błąd" | Order joby nigdy nie failują trwale, ale admin musi wiedzieć o problemie | Zmieniony temat i treść emaila |
+| Cleanup starych jobów po sukcesie | Zapobieganie zaśmiecaniu kolejki stuck jobami sync_payment/sync_status | Delete zamiast cancel — prostsze |
+
+## Deviations from Plan
+
+None — plan executed as written.
+
+## Issues Encountered
+
+| Issue | Resolution |
+|-------|------------|
+| Testy CronJob failowały — mock get() nie zwracał job_type | Dodano job_type do willReturn() w 3 istniejących testach |
+| test.ps1 nie istnieje | Użyto bezpośrednio `php phpunit.phar` |
+
+## Next Phase Readiness
+
+**Ready:**
+- System retry Apilo jest kompletny i odporny na awarie
+- Email notyfikacji daje adminowi pełen kontekst do szybkiej reakcji
+
+**Concerns:**
+- None
+
+**Blockers:**
+- None
+
+---
+*Phase: 09-apilo-email-fix, Plan: 01*
+*Completed: 2026-03-19*