orderPRO/.paul/phases/91-print-client-timeout-resilience/91-01-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, delegation

phase	plan	type	wave	depends_on	files_modified	autonomous	delegation
91-print-client-timeout-resilience	01	execute	1		clients/windows/OrderPROPrint/Services/PollingService.cs clients/windows/OrderPROPrint/Services/PrintApiClient.cs	true	off

## Goal Wyeliminować zawieszanie się OrderPROPrint przy timeout'ach HTTP — aplikacja ma kontynuować polling w nieskończoność niezależnie od błędów sieciowych.

Purpose

Użytkownik zgłasza, że po timeout'cie etykiety przestają się drukować i trzeba ręcznie otworzyć ustawienia i kliknąć Zapisz żeby "odwiesić" program. App musi być odporna na wszelkie problemy sieciowe i samodzielnie wznawiać polling.

Output

Zmodyfikowane pliki PollingService.cs i PrintApiClient.cs z resilient polling.

## Project Context @.paul/PROJECT.md @.paul/ROADMAP.md @.paul/STATE.md

Source Files

@clients/windows/OrderPROPrint/Services/PollingService.cs @clients/windows/OrderPROPrint/Services/PrintApiClient.cs @clients/windows/OrderPROPrint/TrayApplicationContext.cs

<acceptance_criteria>

AC-1: Polling kontynuuje po timeout HTTP

Given aplikacja odpytuje API i serwer nie odpowiada
When HttpClient.Timeout (30s) się wyczerpie
Then polling kontynuuje normalnie w następnym cyklu timera
And ikona tray pokazuje błąd ale wraca do normalnej po udanym poll

AC-2: Polling kontynuuje po zawieszeniu HTTP poza timeout

Given request HTTP zawiesił się i HttpClient.Timeout nie zadziałał (edge case Windows)
When minęło 45 sekund od rozpoczęcia poll
Then CancellationToken wymusza anulowanie requestu
And _isProcessing jest resetowane
And następny cykl timera wykonuje normalny poll

AC-3: Ikona wraca do normalnego stanu po odzyskaniu połączenia

Given polling był w stanie błędu (ikona Error)
When kolejny poll zakończy się sukcesem
Then ikona tray wraca do normalnej (Application)
And tooltip pokazuje aktualny status

</acceptance_criteria>

Task 1: Dodać CancellationToken per-poll i watchdog w PollingService clients/windows/OrderPROPrint/Services/PollingService.cs 1. Dodać pole `private DateTime _pollStartedAt` do klasy.

2. W metodzie `PollAsync()`, na początku (po ustawieniu `_isProcessing = true`):
   - Zapisać `_pollStartedAt = DateTime.UtcNow`
   - Utworzyć `using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(45))`
   - Przekazać `cts.Token` do wszystkich wywołań `_apiClient.*Async()`

3. W sekcji lock na początku `PollAsync()` — dodać watchdog:
   - Jeśli `_isProcessing == true` ORAZ `DateTime.UtcNow - _pollStartedAt > TimeSpan.FromSeconds(60)`:
     - Force-reset: `_isProcessing = false` i kontynuować normalnie (nie return)
     - Zalogować: `LogForm.Log("WATCHDOG: wymuszony reset _isProcessing po 60s")`
   - Jeśli `_isProcessing == true` i NIE przekroczono 60s: return jak dotychczas

4. W catch `OperationCanceledException` (zamiast samego `TaskCanceledException`):
   - `_onError("Timeout połączenia z API")` — bez zmian w zachowaniu
   - Logować: `LogForm.Log("Timeout: poll anulowany przez CancellationToken")`

5. Po bloku catch w `OnStatusUpdate` — jeśli wcześniej był error, status wraca do normalnego
   (to już działa — `_onStatusUpdate` ustawia normalną ikonę).

6. Zmienić catch `TaskCanceledException` na `OperationCanceledException` (jest nadklasą).

Kompilacja projektu: `dotnet build` w katalogu clients/windows/OrderPROPrint/ AC-1 i AC-2 satisfied: timeout i zawieszony request nie blokują kolejnych poll'i Task 2: Dodać CancellationToken do metod PrintApiClient clients/windows/OrderPROPrint/Services/PrintApiClient.cs 1. Dodać parametr `CancellationToken cancellationToken = default` do metod: - `GetPendingJobsAsync(CancellationToken cancellationToken = default)` - `DownloadLabelAsync(int jobId, CancellationToken cancellationToken = default)` - `MarkCompleteAsync(int jobId, CancellationToken cancellationToken = default)`

2. Przekazać `cancellationToken` do każdego wywołania `_httpClient.GetAsync()` / `PostAsync()`:
   - `await _httpClient.GetAsync("api/print/jobs/pending", cancellationToken)`
   - `await _httpClient.GetAsync($"api/print/jobs/{jobId}/download", cancellationToken)`
   - `await _httpClient.PostAsync($"api/print/jobs/{jobId}/complete", null, cancellationToken)`

3. Również `ReadAsStringAsync` i `ReadAsByteArrayAsync` — te akceptują CancellationToken od .NET 5+:
   - `await response.Content.ReadAsStringAsync(cancellationToken)`
   - `await response.Content.ReadAsByteArrayAsync(cancellationToken)`

4. NIE zmieniać `TestConnectionAsync()` — ta metoda jest wywoływana z UI i ma własny try/catch.

Kompilacja projektu: `dotnet build` w katalogu clients/windows/OrderPROPrint/ AC-1 i AC-2 satisfied: CancellationToken propagowany do HTTP calls

DO NOT CHANGE

• clients/windows/OrderPROPrint/TrayApplicationContext.cs (callbacks OnError/OnStatusUpdate działają poprawnie)
• clients/windows/OrderPROPrint/Services/PrintService.cs (druk PDF nie wymaga zmian)
• clients/windows/OrderPROPrint/Forms/* (formularze UI nie wymagają zmian)
• Logika timera (interwał, Start/Stop) pozostaje bez zmian

SCOPE LIMITS

• Nie dodawać retry logic per-request (timer i tak odpyta ponownie)
• Nie dodawać exponential backoff (użytkownik chce stałe odpytywanie)
• Nie zmieniać HttpClient.Timeout (30s jest OK jako pierwszy poziom obrony)
• Nie zmieniać interfejsu publicznego PollingService (Start/Stop/IsRunning)

Before declaring plan complete: - [ ] `dotnet build` kompiluje bez błędów - [ ] CancellationToken przekazywany z PollingService do PrintApiClient do HttpClient - [ ] Watchdog resetuje _isProcessing po 60s - [ ] OperationCanceledException łapany (nie tylko TaskCanceledException) - [ ] Brak regresji: normalne działanie polling → print → mark complete

<success_criteria>

• Wszystkie taski ukończone
• Kompilacja bez błędów
• Watchdog chroni przed zawieszeniem _isProcessing
• CancellationToken wymusza timeout niezależnie od HttpClient.Timeout </success_criteria>

After completion, create `.paul/phases/91-print-client-timeout-resilience/91-01-SUMMARY.md`