debian
0292b03d5e
Deploy PROD / deploy (push) Successful in 19s
Egress zapisuje stan zadan w Redisie, a status koncowy ustawia sam proces obslugujacy nagranie. Gdy proces zostanie ubity razem z kontenerem (restart, wyczerpanie pamieci), status nigdy sie nie zmienia: zadanie figuruje jako EGRESS_ACTIVE **na zawsze**. `StopEgress` konczy sie wtedy sukcesem i NIC NIE ZMIENIA, bo nie ma juz czego zatrzymywac. Sprawdzone na zywo: wpis wisial po restarcie Egress, panel pokazywal go jako osierocone zadanie, a klikniecie "Zatrzymaj" logowalo "Zatrzymano Egress" i zostawialo wszystko po staremu. Zuzycie procesora bylo przy tym zerowe, czyli zadanie faktycznie nie istnialo. Ekran mowil wiec nieprawde i nie dawalo sie tego odkrecic z poziomu aplikacji: wpis usunieto recznie z Redisa. Liczy sie teraz takze WIEK zadania, nie tylko jego status. Osiem godzin: dluzej niz najdluzszy sensowny webinar razem z montazem, a krocej niz doba, zeby wpis po nocnym restarcie nie straszyl rano. `startedAt` jest w nanosekundach od epoki. Proto podaje sam `int64` bez jednostki, ale webhooki LiveKit niosa tam wartosci 19-cyfrowe, a `duration` w `FileInfo` jest liczone tak samo. Zero oznacza zadanie, ktore nie zdazylo wystartowac: traktujemy je jak biezace, zeby swiezo zlecone nagranie nie znikalo z ekranu, zanim ruszy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>