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
Issue with /lab/tree #4009
Comments
Thanks for the report @timkpaine. I think you are correct: there is probably a race condition between the restoration of the filebrowser cwd and the |
@ian-r-rose thanks! its especially noticeable for us because the tree handler default path has like 4 items, but the top level has literally 4000, so its like 2 seconds after page load the directory changes. |
I've been trying to reproduce this with a directory that has 5000 files, and a subdirectory with just one. It seems to be working correctly, as far as I can tell. Is there any other information that you can think of that would be relevant here, @timkpaine? |
I think this might be addressed by #3687. |
Ping @timkpaine - #3687 is now merged into master. Can you see if this is still an issue with that PR merged? |
Closing as resolved. Please add a new comment if we still need to do something or to continue the discussion. |
This is still an issue, let me write a script to generate a directory structure to simulate it |
here is a repro, it will put you in the wrong folder the first time, correct folders on subsequent calls to /lab/tree/test2 #!/bin/bash
mkdir test
cd test
echo "c.NotebookApp.default_url = '/login?next=/lab/tree/test2'" >>test.cfg
for i in `seq 1 10000`; do
touch $i.py
done
mkdir test2
cd test2
touch test.py
cd ../
jupyter lab --config=./test.cfg |
More info, the initial launcher is in the correct sub directory, it's just the file browser that is wrong |
@timkpaine I am still having a hard time reproducing this with your script. Can you confirm that it is still an issue with 0.34.3? |
basically, its possible for the browser model's path to not match what it is showing |
heres the sequence of the cd function being called:
|
from gitter: may race condition with initial |
Fixed by #5224 |
Just tested this locally by adding a delay to the contents API: --- a/packages/services/src/contents/index.ts
+++ b/packages/services/src/contents/index.ts
@@ -1022,6 +1022,16 @@ export class Drive implements Contents.IDrive {
let settings = this.serverSettings;
return ServerConnection.makeRequest(url, {}, settings)
+ .then(response => {
+ if (!options.content) {
+ return response;
+ }
+ return new Promise<Response>(resolve =>
+ setTimeout(() => {
+ resolve(response);
+ }, 5000)
+ );
+ })
.then(response => {
if (response.status !== 200) {
throw new ServerConnection.ResponseError(response); If I have a session where the file browser is sitting in
With the above delay, this will take 15s+ to get the dir listing from the URL arg. |
Ideal resolution:
In all cases, there should only be one API call with |
I think the race condition is fixed, but the initial load still happens. I think the file browser may need some refactoring to prevent its initial API request, so while the current fix is an improvement, it's not a complete fix. I will look at this before 2.0, but it may need to be pushed to a later release. |
If you have a lot of stuff in the top level, and navigate to /lab/tree/a/sub/directory, the subdirectory loads in the file browser, then it redirects to the top directory. I think this is because the calls are asynchronous, and getting the contents of the subdirectory finishes before the top directory, but the other calls should be ignored if the url is /lab/tree.
The text was updated successfully, but these errors were encountered: