fix: static accepter image load fail #654
Conversation
commit: |
| @@ -83,13 +84,19 @@ export const staticAccepterCommitScreenshot = ( | |||
| payload.append('meta', JSON.stringify(meta)); | |||
| } | |||
|
|
|||
| await Promise.all(imagesInfo.map(async (imageInfo, index) => { | |||
| dispatch({type: actionNames.UPDATE_LOADING_TITLE, payload: `Preparing images to commit: ${index + 1} of ${imagesInfo.length}`}); | |||
| const queue = new PQueue({concurrency: 256}); | |||
There was a problem hiding this comment.
Now we limit number of image load requests by 256.
Looks like every browser can handle 256 requests at the same time, and this number seems reasonable as http/2 supports this amount.
But if there are too many requests, browser can have some difficulties
There was a problem hiding this comment.
if this works then ok, but if 256 is the max value in most browsers, maybe it's worth limiting it slightly below the limit to preserve room for other, unrelated to images uploading requests? For example, so that when user is uploading images, he could still use report (including downloading time travel snapshots or downloading screenshots for other tests).
There was a problem hiding this comment.
256 is just "how much request can you typically perform at the same time with http 2"
Browser would be fine with numbers above it, while it is not above 1k
| })); | ||
| payload.append('image', blob, imagesInfo[i].path); | ||
|
|
||
| dispatch({type: actionNames.UPDATE_LOADING_TITLE, payload: `Preparing images to commit: ${i + 1} of ${imagesInfo.length}`}); |
There was a problem hiding this comment.
dispatching this action after the blob is downloaded seems more suitable.
Example: we have 256 images.
Before:
We instantly dispatch 256 actions and user sees "preparing to commit: 256/256" (and only after we only start downloading these images)
After:
We update the counter after download is complete. So at start user will see "0/256" while nothing was downloaded
| export function getBlob(url) { | ||
| return new Promise((resolve, reject) => { | ||
| const xhr = new XMLHttpRequest(); | ||
| export async function getBlobWithRetires(url, retriesCount = 3) { |
There was a problem hiding this comment.
We can also be rps limited
So exponential retries (1s, 2s, 4s) would not be superfluous
| @@ -83,13 +84,19 @@ export const staticAccepterCommitScreenshot = ( | |||
| payload.append('meta', JSON.stringify(meta)); | |||
| } | |||
|
|
|||
| await Promise.all(imagesInfo.map(async (imageInfo, index) => { | |||
| dispatch({type: actionNames.UPDATE_LOADING_TITLE, payload: `Preparing images to commit: ${index + 1} of ${imagesInfo.length}`}); | |||
| const queue = new PQueue({concurrency: 256}); | |||
There was a problem hiding this comment.
if this works then ok, but if 256 is the max value in most browsers, maybe it's worth limiting it slightly below the limit to preserve room for other, unrelated to images uploading requests? For example, so that when user is uploading images, he could still use report (including downloading time travel snapshots or downloading screenshots for other tests).
f420a3b to
8d47962
Compare
No description provided.