debian
4203ca036e
Deploy PROD / deploy (push) Successful in 19s
Ekran Zasoby pozwalal POSPRZATAC osierocone nagrania, ale nie zapobiegal ich powstawaniu. Dwie sciezki tworzyly je dalej: - `RecordingService.delete` kasowal wpis, zostawiajac zadanie dzialajace u dostawcy w nieskonczonosc, - `WebinarService.delete` kasowal nagrania KASKADOWO, przez co trwajace zadanie stawalo sie niewidoczne dla aplikacji: scheduler domykajacy nagrania szuka po naszych wpisach, a tych juz nie bylo. Ta druga sciezka wywolala realny incydent: webinar usunieto w trakcie nagrywania, a przegladarka po stronie Egress krecila sie kilkanascie godzin i zjadala jedna piata procesora na serwerze dzielonym z dwiema innymi aplikacjami. Zaden ekran tego nie pokazywal. Obie zatrzymuja teraz zadanie PRZED skasowaniem wpisu. BLAD ZATRZYMANIA NIE BLOKUJE USUNIECIA Najczestsza przyczyna to zadanie, ktore samo sie juz zakonczylo, a administrator ma prawo posprzatac wpis niezaleznie od tego, co odpowie dostawca. Slad idzie do logu, a zadanie mimo wszystko dzialajace pokaze ekran Zasoby jako osierocone, razem z przyciskiem zatrzymania. Zabezpieczenie dziala wiec z dwoch stron: zapobiega i naprawia. Sprawdzone, ze nie powstaje cykl zaleznosci: `LiveKitEgressService` zalezy wylacznie od repozytoriow, ustawien i fabryki dostawcow, wiec nie siega z powrotem ani do `RecordingService`, ani do `WebinarService`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>