#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?
@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
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.
@PortowySzczur: A jeżeli wyciągniemy pojedyncze promise z promise.all, i przynajmniej na pierwszym promise wypadnie 403 -> poleci redirect, i nie dojdzie do wykonania pozostałych. Wtedy ominie się cancellation czyż nie?
@PortowySzczur: gurwa wyskoczył mi taki kwiatek i się tak z-------m w akcji, że sie nie skupiłem na promise.all a na fetchu xD -> ta, jak mówiłem o tym że potrzebuje potwierdzenia to już wiedziałem ocb. Ale dziękuje za wysiłek z wklejaniem mozilli <3
@PortowySzczur tak samo z rozdzielaniem promise.all, nie obędzie się bez przepisania testów. Także będzie więcej roboty albo ziomek mi to klepnie. Ale ogólnie jeszcze raz podziękował :>
@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?
@lukaszwasyl @PortowySzczur "ziomuś" chodzi o to że nikt wyżej nie odróżnia cancelled od rejected, choćby się Promise.all zesrał na malinowo to w specyfikacji nie ma żadnego połączenia z cancellowaniem requestów https://tc39.es/ecma262/#sec-promise.all więc albo wprowadzacie OPa w błąd albo sam nie odróżnia cancelled od rejected
@tlaziuk: Jakiś dziwnych fetchy pomiędzy nie mam, fetch na te zasoby *może być jakoś z-----y. 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
@lukaszwasyl z tego speca https://fetch.spec.whatwg.org/#response-class rozumiem że musisz w kodzie uzyskać dostęp do body jeśli nie jest ono puste (czyli wywołanie metody json itp), w przeciwnym wypadku ReadableStream zostanie "aborted" co odpowiadało by Twojemu przykładowi - kod sprawdza jedynie status odpowiedzi
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?
@LM317K:
ogólnie dużo się dzieje nad tą funkcją. Promise.all(x,y,z...) dla x,y,z jest wywoływana fetch func