-
Notifications
You must be signed in to change notification settings - Fork 959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preflight request is not logged to console, double preflight received only starts upload connection for the last one #2965
Comments
I have tried reproducing this with a standalone project but it was a lot more stuff to wire up than I thought, so I'll let you at least read the issue and maybe ask for more feedback before I spend the hours to do that 😅 |
Something is wonky in internal state here it seems. I modified my hook to keep a copy of the original file list and be able to retry uploading from it if a file is stalled.
Retry handler:
Doing that only triggers validate, and nothing else. As you can see in the logs below there is a long list of files in the ´:files` upload, but not the retried file, so the cancel upload removes it from the state as it should, but still does not want to re-upload it.
The only somewhat user friendly "workaround" for now is to let users delete files, then track those deleted files in a text list close to the file picker, so they can see what files they manually need to re-choose. Or alternatively I need to implement de-duping so they can just choose the whole folder again and we'll simply skip any items that are .done?. |
Hello again! I had time to make a minimal repro (it is insane how nice it is to do this quickly with elixirscript):
To use, simply download the random files zip file attached (it is 10 files of 150kb with randomly generated content). Select all of them for upload and you should be getting something similar to this: Just with other placements. |
From my observations, there seems to be some kind of race condition here, because with the no-op writer that does not go to R2(S3), it happens waaay more frequent. The largest amount I saw was four entries in one preflight response. Edit: Also ignore the fact that I am not using / setting the max concurrency stuff and just hardcode 3 in both ends. I tried as best I could to pull this out of a real app to reproduce it properly :P |
Please try |
Hello, same issue, multiple entries come back and the liveview js code does not seem to handle this: It is interesting that it seems to be fairly deterministic that it always fails on file nr 4. I initially feed 3 files to the uploader and then feed one and one more. I will have more time later this week to try to do some pointed debug-logging and see if I can figure out why it doesn't properly handle multiple preflight entry responses. |
If that’s in your single file script make sure to also update the |
* track in-progress preflights (fixes #2965) * Update assets/js/phoenix_live_view/upload_entry.js --------- Co-authored-by: Chris McCord <[email protected]>
@SteffenDE indeed, giga brainfart there, it works like a charm!!! thanks a dozen :) |
* track in-progress preflights (fixes #2965) * Update assets/js/phoenix_live_view/upload_entry.js --------- Co-authored-by: Chris McCord <[email protected]>
Environment
Actual behavior
I am making a "continous uploader" basically using a client side queue and some "send next chunk" functionality. It seems that under load there is some unexpected behaviour. This is especially seen with multiple very small files. I am uploading textures and one big OBJ file.
Basically the gist of it is that sometimes, there is no output of the "sending preflight request" console output. When inspecting the console I see the log for the file before and then the preflight response comes in with two entries. The IEX console then only shows the latter of those two entries connecting and starting the upload.
The websocket messages shows this:
With the response as expected, one entry for the preflight request.
Then the next allow upload called from the client is for the file after the stalled one
With a reply containing two entries:
Interestingly you can see the stalled file in the diff with the correct ref. However the entry for ref 6 (stalled file) is simply ignored.
I hope this is detailed enough for you to understand where in the javascript code(?) there is a bug and how the liveview ends up with the correct list of entries/refs and even a responded entry when there is not a single trace of the stalled file being sent up as an event.
My clientside code is extremely terse and just listens to an even that is sent based on handle_progress on the serverside.
Pertinent entries here:
Hook:
Pertinent parts of the liveview:
I am omitting the upload writer, it should be irrelevant. I wrote filenames to a log file in the
init
of the writer, and the stalled file never made it there. Which makes sense because the upload thing never connected and produced a[info] JOINED lvu:36 in 197ms Parameters: %{"token" => "SFMyNTY.g2gDaAJhBXQAAAADdwNwaWRYdw1ub25vZGVAbm9ob3N0AAAF-AAAAAAAAAAAdwNyZWZoAm0AAAAUcGh4LUY2UW42bVVjZUk2U1RRRWttAAAAAjM2dwNjaWR3A25pbG4GAJt1VKKMAWIAAVGA.XG--dovnR7h0RqqOY_3i4divuMF1_fJFFPh9gqJUb6k"}
like message (which is the process the upload writer is initialized and lives).Expected behavior
Uhm, good question.
Either that the preflight is sent like it should or that the client can handle getting a double preflight response entry thing back.
Edit: Removed the first part of the issue that was based on screenshots, because apparently the screenshots didn't work and the work of pulling this out of the websocket log gave good insight anyways
The text was updated successfully, but these errors were encountered: