Wpis z mikrobloga

#pytanie o error handling w #javascript
Robię fetcha. Jedną z możliwych odpowiedzi jest odpowiedź z 403. Przy symulacji odpowiedzi z 403(incognito bez cookies, zawsze mi zwraca taką odpowiedź) za pierwszym razem przekierowuje na bezpieczny url. Za drugim razem gdy odpalam ten sam URL, dostaje 403 na danym zasobie(co jest prawidłowym zachowaniem) oraz 2x cancelled na inny url. Z czego mogą wynikać dodatkowe, scancellowane requesty?
  • 17
@PortowySzczur: OO to może być to. Potrzebuje jakiegoś potwierdzenia bo mi TL zrejectował ten kod (backendowiec JS nope), ogólnie robie fetcha i jak 403 wywala to ma redirectować. fetch na ścieżkę leci raz później są zcanellowane fetche. Więc możesz mieć racje. Gość tłumaczy to kwestią performance
via Wykop Mobilny (Android)
  • 1
@lukaszwasyl:

Promise.all() will reject immediately upon any of the input promises rejecting. In comparison, the promise returned by Promise.allSettled() will wait for all input promises to complete, regardless of whether or not one rejects. Consequently, it will always return the final result of every promise and function from the input iterable.
konto usunięte via Wykop Mobilny (Android)
  • 0
@lukaszwasyl Promise nijak się ma do tego że cancelluje requesty, żeby anulować request trzeba użyć albo AbortController albo XHR - w Twoim przykładzie pseudokodu nie ma ani tego ani tego, może masz w środowisku jakiegoś customowego fetcha? Albo nie używasz Promise tylko Observer?
@tlaziuk: Jakiś dziwnych fetchy pomiędzy nie mam, fetch na te zasoby *może być jakoś #!$%@?. Promise.all(x,y,z) gdzie x,y,z to try/catch dla wywołania funkcji z fetchem. Status w networku to 403 dla fetch na dany zasób, później następny rekord to ewidentnie jest "(cancelled)" w developerskich. " AbortController albo XHR" nope, nigdzie takich konstrukcji w kodzie tam nie widziałem wokół tego problemu