fix: naprawiono wysyłkę zamówień do Apilo — brakujące $apiloRepository w closurach cron.php
Regresja z ver. 0.339 (split IntegrationsRepository → ApiloRepository): $apiloRepository nie było w use() 5 handlerów cron.php. Dodano retry zamówień z apilo_order_id=-1 co 1h. Dodano powiadomienia mailowe o błędach sync Apilo. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
186
.paul/phases/08-apilo-orders-fix/08-01-PLAN.md
Normal file
186
.paul/phases/08-apilo-orders-fix/08-01-PLAN.md
Normal file
@@ -0,0 +1,186 @@
|
||||
---
|
||||
phase: 08-apilo-orders-fix
|
||||
plan: 01
|
||||
type: execute
|
||||
wave: 1
|
||||
depends_on: []
|
||||
files_modified: [cron.php, autoload/Domain/Integrations/ApiloRepository.php]
|
||||
autonomous: false
|
||||
---
|
||||
|
||||
<objective>
|
||||
## Goal
|
||||
Zdiagnozować dlaczego zamówienia przestały się wysyłać do apilo.com, naprawić przyczynę, i zapewnić wysłanie zaległych zamówień.
|
||||
|
||||
## Purpose
|
||||
Zamówienia nie trafiają do systemu realizacji (Apilo) — blokuje to obsługę klientów i wysyłkę paczek. Krytyczny bugfix produkcyjny.
|
||||
|
||||
## Output
|
||||
- Zidentyfikowana i naprawiona przyczyna braku wysyłki zamówień
|
||||
- Zaległe zamówienia (apilo_order_id = NULL lub -1) gotowe do wysłania przez cron
|
||||
</objective>
|
||||
|
||||
<context>
|
||||
## Project Context
|
||||
@.paul/PROJECT.md
|
||||
@.paul/ROADMAP.md
|
||||
@.paul/STATE.md
|
||||
|
||||
## Source Files
|
||||
@cron.php (linie 197-521 — handler APILO_SEND_ORDER)
|
||||
@autoload/Domain/Integrations/ApiloRepository.php (token management, API calls)
|
||||
@autoload/Domain/Integrations/IntegrationsRepository.php (getSettings)
|
||||
@autoload/Domain/Integrations/ApiloLogger.php (logging)
|
||||
@autoload/Domain/Order/OrderAdminService.php (sendOrderToApilo, sync methods)
|
||||
|
||||
## Technical Context — Apilo Order Flow
|
||||
1. Cron pobiera zamówienia z `apilo_order_id = NULL` i `date_order >= sync_orders_date_start`
|
||||
2. Warunki wysyłki (linia 200): enabled=1, sync_orders=1, access-token exists, sync_orders_date_start <= now
|
||||
3. Jeden order per cron run (LIMIT 1)
|
||||
4. Failure markers: -1 = permanent HTTP error, -2 = zerowe ceny (oba NIE są retried automatycznie)
|
||||
5. Token keepalive: co 5min, refresh 300s przed wygaśnięciem
|
||||
6. Config: pp_shop_apilo_settings (key-value, provider='apilo')
|
||||
|
||||
## User Context
|
||||
Użytkownik dodał dostępy do bazy danych w config.php. Zamówienia nie wysyłają się do apilo.com — potrzebna diagnoza i naprawa.
|
||||
</context>
|
||||
|
||||
<skills>
|
||||
## Required Skills (from SPECIAL-FLOWS.md)
|
||||
|
||||
No specialized flows required for hotfix debugging.
|
||||
</skills>
|
||||
|
||||
<acceptance_criteria>
|
||||
|
||||
## AC-1: Przyczyna zdiagnozowana
|
||||
```gherkin
|
||||
Given zamówienia przestały się wysyłać do Apilo
|
||||
When przeanalizuję logi (pp_log), ustawienia Apilo (pp_shop_apilo_settings), i konfigurację crona
|
||||
Then zidentyfikuję konkretną przyczynę problemu (np. wygasły token, wyłączona sync, błąd API)
|
||||
```
|
||||
|
||||
## AC-2: Przyczyna naprawiona
|
||||
```gherkin
|
||||
Given znana przyczyna braku wysyłki
|
||||
When zastosuję poprawkę (kod lub konfiguracja)
|
||||
Then nowe zamówienia będą się poprawnie wysyłać przez cron do Apilo
|
||||
```
|
||||
|
||||
## AC-3: Zaległe zamówienia gotowe do wysłania
|
||||
```gherkin
|
||||
Given istnieją zamówienia z apilo_order_id = NULL lub -1 które powinny być w Apilo
|
||||
When zresetuję failed orders (apilo_order_id = -1 → NULL) i sprawdzę że cron je przetworzy
|
||||
Then zaległe zamówienia wyślą się do Apilo przy kolejnych uruchomieniach crona
|
||||
```
|
||||
|
||||
</acceptance_criteria>
|
||||
|
||||
<tasks>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 1: Diagnoza — sprawdzenie logów i konfiguracji Apilo</name>
|
||||
<files>cron.php, autoload/Domain/Integrations/ApiloRepository.php, autoload/Domain/Integrations/IntegrationsRepository.php</files>
|
||||
<action>
|
||||
Sprawdzić przyczynę problemu analizując:
|
||||
|
||||
1. **Logi Apilo na serwerze** — pobrać logs/apilo.txt z FTP (zgodnie z CLAUDE.md: "Za każdym razem jak próbujesz sprawdzić jakiś plik z logami spróbuj go najpierw pobrać z serwera FTP")
|
||||
2. **Logi w bazie** — sprawdzić ostatnie wpisy w pp_log (action LIKE '%apilo%' lub '%send_order%') — kiedy ostatni sukces, czy są errory
|
||||
3. **Ustawienia Apilo** — sprawdzić pp_shop_apilo_settings:
|
||||
- enabled = 1?
|
||||
- sync_orders = 1?
|
||||
- access-token istnieje i nie wygasł? (access-token-expire-at vs now)
|
||||
- refresh-token istnieje i nie wygasł?
|
||||
- sync_orders_date_start — jaka data?
|
||||
- token-keepalive-at — kiedy ostatni keepalive?
|
||||
4. **Zaległe zamówienia** — ile jest zamówień z apilo_order_id = NULL i z -1?
|
||||
5. **Cron execution** — czy cron.php jest w ogóle wywoływany? (sprawdzić pp_cron_jobs — czy są scheduled/processed joby)
|
||||
|
||||
Na podstawie diagnozy określić przyczynę i plan naprawy.
|
||||
</action>
|
||||
<verify>Przyczyna zidentyfikowana i udokumentowana</verify>
|
||||
<done>AC-1 satisfied: Znana przyczyna braku wysyłki zamówień</done>
|
||||
</task>
|
||||
|
||||
<task type="checkpoint:decision" gate="blocking">
|
||||
<decision>Wybór strategii naprawy na podstawie diagnozy</decision>
|
||||
<context>Bez diagnozy nie wiemy co dokładnie naprawić. Przyczyna może być: wygasły token OAuth, wyłączona synchronizacja, błąd w kodzie, problem z cronem, lub inna przyczyna.</context>
|
||||
<options>
|
||||
<option id="option-token">
|
||||
<name>Naprawa tokenu OAuth</name>
|
||||
<pros>Jeśli token wygasł — refresh lub re-autoryzacja naprawi problem</pros>
|
||||
<cons>Wymaga dostępu do panelu admina lub bezpośredniej zmiany w DB</cons>
|
||||
</option>
|
||||
<option id="option-config">
|
||||
<name>Naprawa konfiguracji (settings)</name>
|
||||
<pros>Proste — zmiana wartości w pp_shop_apilo_settings</pros>
|
||||
<cons>Może nie być jedyną przyczyną</cons>
|
||||
</option>
|
||||
<option id="option-code">
|
||||
<name>Naprawa kodu (bug w cron.php lub ApiloRepository)</name>
|
||||
<pros>Trwała naprawa jeśli problem jest w logice</pros>
|
||||
<cons>Wymaga deployu nowego kodu na serwer</cons>
|
||||
</option>
|
||||
<option id="option-other">
|
||||
<name>Inna przyczyna (cron nie działa, serwer, API Apilo)</name>
|
||||
<pros>Identyfikacja zewnętrznego problemu</pros>
|
||||
<cons>Może wymagać działań poza kodem</cons>
|
||||
</option>
|
||||
</options>
|
||||
<resume-signal>Po diagnozie — wybierz strategię naprawy lub opisz co znalazłeś</resume-signal>
|
||||
</task>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 3: Naprawa i reset zaległych zamówień</name>
|
||||
<files>cron.php, autoload/Domain/Integrations/ApiloRepository.php</files>
|
||||
<action>
|
||||
Na podstawie wybranej strategii:
|
||||
|
||||
1. **Zastosować poprawkę** (kod, konfiguracja, lub token refresh)
|
||||
2. **Reset failed orders** — zamówienia z apilo_order_id = -1 które powinny być wysłane:
|
||||
- Przygotować query: UPDATE pp_shop_orders SET apilo_order_id = NULL WHERE apilo_order_id = -1 AND date_order >= '{sync_start_date}'
|
||||
- LUB użyć sendOrderToApilo() z panelu admina dla poszczególnych zamówień
|
||||
3. **Weryfikacja** — uruchomić cron.php ręcznie i sprawdzić czy zamówienie się wysyła
|
||||
|
||||
Unikać: resetowania zamówień z apilo_order_id = -2 (zerowe ceny — świadomy skip)
|
||||
</action>
|
||||
<verify>Ręczne uruchomienie cron.php wysyła zamówienie do Apilo (sprawdzić pp_log i response)</verify>
|
||||
<done>AC-2 + AC-3 satisfied: Przyczyna naprawiona, zaległe zamówienia gotowe do wysłania</done>
|
||||
</task>
|
||||
|
||||
</tasks>
|
||||
|
||||
<boundaries>
|
||||
|
||||
## DO NOT CHANGE
|
||||
- autoload/Domain/Order/OrderRepository.php (order creation logic)
|
||||
- autoload/Domain/CronJob/ (cron job infrastructure)
|
||||
- Logika obsługi płatności i statusów w cron.php (handlers 3-11)
|
||||
|
||||
## SCOPE LIMITS
|
||||
- Tylko diagnoza i naprawa problemu wysyłki zamówień do Apilo
|
||||
- Nie refaktoryzować kodu cron.php ani ApiloRepository
|
||||
- Nie zmieniać flow tworzenia zamówień
|
||||
- Nie dodawać nowych funkcji (np. auto-retry)
|
||||
|
||||
</boundaries>
|
||||
|
||||
<verification>
|
||||
Before declaring plan complete:
|
||||
- [ ] Przyczyna braku wysyłki zidentyfikowana
|
||||
- [ ] Poprawka zastosowana (kod lub konfiguracja)
|
||||
- [ ] Przynajmniej jedno zamówienie wysłane do Apilo po naprawie
|
||||
- [ ] Zaległe zamówienia zresetowane (apilo_order_id = NULL) i gotowe do przetworzenia
|
||||
- [ ] Brak nowych błędów w logach po naprawie
|
||||
</verification>
|
||||
|
||||
<success_criteria>
|
||||
- Przyczyna zdiagnozowana i udokumentowana
|
||||
- Nowe zamówienia wysyłają się poprawnie przez cron
|
||||
- Zaległe zamówienia z apilo_order_id = NULL/-1 zresetowane i gotowe do wysłania
|
||||
- Brak regresji w istniejącej funkcjonalności
|
||||
</success_criteria>
|
||||
|
||||
<output>
|
||||
After completion, create `.paul/phases/08-apilo-orders-fix/08-01-SUMMARY.md`
|
||||
</output>
|
||||
Reference in New Issue
Block a user