Dzień dobry,
Zgłaszam powtarzający się problem w naszej instalacji self-hosted EZD RP, licząc że może ktoś z forum spotkał się z czymś podobnym — nie jesteśmy administracją publiczną, więc nie mamy dostępu do oficjalnego wsparcia NASK dla tej instalacji.
Środowisko:
- Self-hosted, RKE2 (Kubernetes), Ubuntu 24.04, pojedynczy VPS
- Ruch przychodzący przez Cloudflare Tunnel (
cloudflared), bez bezpośredniej ekspozycji portów na świat filerepo-apiskonfigurowane w trybie S3, przechowywanie plików na Cloudflare R2 (nie AWS S3)
Konfiguracja S3 użyta dla zgodności z R2 (sekcja filerepository.persistence.s3 w Helm values):
yaml
disable_payload_signing: true
disable_default_checksum_validation: true
force_path_style: true
region: auto
(bez tych dwóch pierwszych flag występował błąd STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER not implemented — R2 nie wspiera tego wariantu podpisywania uploadów, który domyślnie próbuje wymusić klient .NET AWS SDK).
Opis problemu:
Dokumenty ręcznie przypisywane do konkretnej sekcji/folderu w obrębie sprawy (przeciąganie/przypisanie w widoku “Akta sprawy”) poprawnie tam trafiają w momencie przypisania. Jednak po pewnym czasie (obserwowaliśmy to wielokrotnie, m.in. z dnia na dzień) część z tych dokumentów pojawia się z powrotem luzem, na głównej liście akt sprawy, poza swoją sekcją — mimo że nikt ręcznie ich stamtąd nie usuwał ani nie przenosił.
Problem jest powtarzalny, dotyczy różnych dokumentów w różnych dniach, i nie ogranicza się do dokumentów utworzonych tego samego dnia — obserwowaliśmy to też dla dokumentów przypisanych dzień wcześniej.
Co już sprawdziliśmy / wykluczyliśmy:
- Logi
ezdrp-apiifilerepo-apiz okresu występowania problemu — brak jakichkolwiek błędów/wyjątków korelujących w czasie z momentem “wypadnięcia” dokumentów. - Baza danych, schemat
workspace, tabelaDokumentPrzestrzeni— kolumnyIdSekcjaorazIdNadrzednyDokumentPrzestrzenisą puste (NULL) zarówno dla dokumentów, które “wypadły”, jak i dla dokumentów, o których wiemy na pewno, że są poprawnie widoczne w swojej sekcji — co sugeruje, że mechanizm przypisania do sekcji nie jest realizowany przez te dwie kolumny (albo szukamy w niewłaściwym miejscu). - Zapytanie po kluczach obcych (
information_schema.table_constraints) wskazujących na tabeleDokument/DokumentWersja— zwróciło 0 wyników, co sugeruje brak formalnych ograniczeń FK w tym miejscu schematu. - Pełne wyczyszczenie cache Redis (
FLUSHALL) — bez wpływu na problem, dokumenty nadal widoczne poza sekcją po odświeżeniu. - Cache przeglądarki / ewentualny cache po stronie Cloudflare — sprawdzone w trybie incognito, wynik bez zmian.
Pytania do społeczności:
- Czy ktoś spotkał się z podobnym zachowaniem, szczególnie przy instalacjach z niestandardowym (nie-AWS) backendem S3 dla
filerepo-api? - Czy mechanizm przypisania dokumentu do sekcji/folderu jest realizowany asynchronicznie (np. przez integrator/kolejkę zdarzeń), co mogłoby tłumaczyć niespójność między tym, co widać “od razu” po przypisaniu, a stanem po jakimś czasie?
- Czy w innym miejscu schematu bazy (poza
workspace.DokumentPrzestrzeni) przechowywane jest rzeczywiste przypisanie dokumentu do sekcji — jeśli ktoś orientuje się w strukturze bazy, chętnie przyjmę wskazówkę, w której tabeli/kolumnie tego szukać.
Będę wdzięczny za każdą sugestię — dane są u nas bezpieczne (mamy pełny, cogodzinny backup poza serwerem), ale chcielibyśmy zrozumieć i naprawić przyczynę, zamiast ręcznie poprawiać to za każdym razem.
Dziękuję za pomoc.