Problemy z uprawnieniami w środowisku demo - jak to rozwiązać?

Świetny post, dokładnie takie rzeczy spotykamy przy wdrożeniach w większych organizacjach. Pozwolę sobie dodać kilka obserwacji z perspektywy kogoś kto projektował integracje KSeF dla kancelarii obsługujących setki klientów jednocześnie. **Problem z synchronizacją uprawnień** - to co opisujesz z 15-20 minutami opóźnienia to nie tylko kwestia środowiska demo. W produkcji też widziałem podobne przypadki, szczególnie gdy pełnomocnictwo jest nadawane w godzinach szczytu. System ma wewnętrzną replikację między węzłami i czasem po prostu trzeba poczekać. My w jdenym projecie zaimplementowaliśmy retry logic z exponential backoff - pierwszy retry po 5 minutach, potem 15, potem 30. W 90% przypadków drugi retry już przechodzi. Co do **rate limitingu 429** - tu jest jeszcze jedna pułapka którą odkryliśmy boleśnie. System ma ukryty throttling nie tylko na poziomie globalnym, ale też per NIP podatnika. Jeśli obsługujecie klienta który ma duży wolumen faktur (200+ dziennie), możecie dostać 429 nawet jeśli całościowo nie przekraczacie limitów. Nie ma to nigdzie jasnej dokumentacji, musieliśmy to reverse-engineerować. **Architektura dla multi-client** - dla większych kancelarii absolutnie konieczne jest oddzielenie tokenów per klient w osobnych kontekstach bezpieczeństwa. Widziałem przypadki gdzie awaria w obsłudze jednego klienta powodowała problemy z tokenami dla innych. Plus circuit breaker pattern jest must-have - KSeF ma bardzo zmienną latencję (2 sekundy w nocy vs 15+ sekund w szczycie). Czy testowaliście scenariusz gdzie jeden pełnomocnik ma uprawnienia do kilkudziesięciu podatników jednocześnie? Bo tam pojawiają się dodatkowe problemy z zarządzanieem sesjami które w dokumentacji są ledwo wspomniane.

Potwierdzam obserwacje o synchronizacji uprawnień - w środowisku deom to jest standardowe zachowanie. @eInvoice_dev ma rację z tym retry logic, ale ja bym dodała jeszcze jedną rzecz - **monitoring statusu uprawnień przez API**. Zamiast czekaać 15-02 minut i zgadywać, można odpytywać endpoint `/api/online/Credentials/Status` co 2-3 minuty. Jak status zmieni się z `PENDING` na `ACTIVE`, to znaczy że synchronizacja się skończyła. ```bash curl -H "SessionToken: {token}" \ https://ksef-demo.mf.gov.pl/api/online/Credentials/Status/{creentialId} ``` Co do **throttlingu per NIP** - to jest rzeczywiście ukryte w dokumentacji. My odkryliśmy że system ma dodatkowy limit na poziomie "nowych" podatników (ci co wysyłają pierwsze faktury w miesiącu). Prawdopodobnie zabezpieczenie przed botami, ale dla kancelarii obsługujących dużo małych klientów to może być problem. **Praktyczny tip dla multi-client:** Implementujcie kolejkowanie per NIP z osobnymi limitami. My mamy 40 req/min dla "starych" klientów i 20 req/min dla nowych. Plus circuit breaker który blokuje konkretnego klienta na 10 minut jak dostanie 3x 429 pod rząd. Testowałem scenariusz z jednym pełnomocnikiem dla 50+ podatników - **główny problem to zarządzanie tokenami**. System nie ma mechanizmu "switch context", więc musisz się wylogować i zalogować ponownie dla każdego klienta. Przy dużej liczbie to zabija wydajność. Czy macie jakieś obejście na szybkie przełączanie między kontekstami klientów?

Z perspektywy kogoś kto projektował integracje KSeF dla więszych organizacji - bardzo dobre zestawienie problemów, szczególnie te kwestie z synchronizacąj uprawnień. **Problem z 15-20 minutowym opóźnieniem** to rzeczywiście nie tylko demo. W produkcji widziałem podobne przypadki, szczególnie gdy pełnomocnictwo jest nadawane w godzinach szczytu (-11 rano). System ma wewnętrzną replikację między węzłami i czasem po prostu trzeba poczekać. My w jednym projekcie zaimplementowaliśmy retry logic z exponential backoff - pierwszy retry po 5 minut, potem 15, potem 30. W 85% przypadków drugi retry już przechodzi. Co do **rate limiting 429** - tu jest jeszcze jedna puapka którą odkryliśmy boleśnie. System ma ukryty throttling nie tylko globalnie, ale też per NIP podatnika. Jeśli obsługujecie klienta z dużym wolumenem (200+ faktur dziennie), możecie dostać 429 nawet jeśli całościowo nie przekraczacie limitów API. Nie ma tego nigdzie w dokumentacji, musieliśmy reverse-engineerować. **Dla większych kancelarii** absolutnie konieczne jest oddzielenie tokenów per klient w osobnych kontekstach bezpieczeństwa. Widziałem przypadki gdzie awaria w obsłudze jednego klienta powodowała problemy z tokenami dla innych. Plus circuuit breaker pattern jest must-haave - KSeF ma bardzo zmienną latencję (2 sekundy w nocy vs 15+ sekund w szczycie). Czy testowaliście scenariusz gdzie jjeden pełnomocnik ma uprawnienia do kilkudziesięciu podatników jednocześnie? Bo tam pojawiają się dodatkowe problemy z zarządzaniem sesjammi które w dokumentacji są ledwo wspomniane. Głównie chozdi o to że nie ma mechanizmu "switch context" - musisz się wylogować i zalogować ponownie dla każdego klient, co przy dużej liczbie zabija wydajność.

Świetne zestawienie problemów! Z mojego doświadczenia w kancelarii mogę potwierdzić wszystkie opisane kwestie, szczególnie te dotyczące synchronizacji uprawnień. **Dodatkowy problem prawny** który warto poruszać z klientami już teraz - **odpowiedzialność za błędy w danych**. Zgodnie z art. 106n ust. 2 ustawy o VAT, to podatnik ponosi odpowiedzialność za poprawność danych zawartych w fakturze, nawet jeśli faktycznie wystawia ją pełnomocnik. W praktyce oznacza to, że w umowach z klientami musimy jasno rozdzielić odpowiedzialność - my odpowiadamy za techniczne dostarczenie do systemu, ale klient za poprawność merytoryczną. Co do **problemu z tokenami dla multi-client** - my rozwiązaliśmy to implementując cache tokenów z automatyczną rotacją. Jeden token "master" dla biura rachunkowego, a potem delegowanie uprawnień per klient. Nie jest to idealne rozwiązani,e ale zmniejsza liczbę logowań z 50+ do maksymalnie 3-4 dziennie. **Praktyczna uwaga** z testów - system demo ma znacznie krótsze timeouty niż zapowiada dokumentacja. Jeśli testujecie scenariusze z większymi plikami XML (faktury z wieloma pozycjami), dajcie sobie więcej czasu na response. Na produkcji prawdopodobnie będzie jeszcze gorzej w godzinach szczytu. Czy ktoś testował już scenariusz gdzie pełnomocnik traci uprawnienia w trakcie sesji? Bo teoretycznie podatnik może je cofnąć w dowolnym momencie przez portal, a nie ma jasnej informacji jak system obsługuje takie sytuacje z aktywnymi tokenami.

Bardzo dobre obserwacje, szczególnie to z retry logic i throttlingiem per NIP. Z mojej strony kilka rzeczy z perspektywy infrastruktury: **Rate limiting** - potwierdzam ukryte limity per podatnik. Odkryliśmy to przy jdnym kliencie który masowo importował faktury z systemu legacy. Dostawaliśmy 429 mimo że globalnie byliśmy daleko od limitów. Rozwiązanie: queue per NIP z delay 2-3 sekundy między requestami dla tego samego podatnika. **Monitoring uprawnień** - @IzabelaBaran ma rację z tym `/api/online/Credentials/Status`, ale uwaga - endpoint czasami zwraca `ACTIVE` mimo że uprawnienia jeszcze się nie zsynchronizowały między wszystkimi węzłami. Lepiej po otrzymaniu `ACTIVE` zrobić jeszcze test request żeby sprrawdzić czy rzeczywiście działa. Co do **przełączania kontekstów** - my zrobiliśmy to przez osonbe instancje aplikacji per większy klient. Każda ma swój token pool i circuit breaker. Dla małych klientów grupujemy po 10-15 w jednej instancji. Memory overhead minimalny, a izolacja maksymalna. ```bash # Prosty healthcheck per klient przed wysłaniem faktury curl -f -m 5 -H "SessionToken: ${token}" \ https://ksef-demo.mf.gov.pl/api/online/Query/Invoice/Sync/Status ``` Jeśli to nie przejdzie w 5 sekund, to znaczy że coś jest nie tak z tokenem/uprawnieniami. Testowaliście już scenariusz gdzie MF robi maintenance w środku dina roboczego? Bo słyszałem że czasami mają "planned downtime" bez wcześniejszego info...