SOLID SERVER: Switching file directories causes the server to crash

[tonypioneer]

Describe the Bug

In Solid File Browser, if we switch the current directory to another directory (such as Home or POD Root) while it is still loading, the Solid server will crash.

This issue will happen in all the Solid servers, including the servers running the latest version of CSS.

To Reproduce

It is a consistently reproducible problem and can be reproduced as follows:

• Run the SolidUI Example App (branch: tony/153_refactor_file_browsing_code)
• Open the All POD Files page. While the page is still loading, click the Back to POD Root button. The server will then stop.

The key point in step two is to switch directories while the File Browser is still loading the file list of the current directory.

Expected Behaviour

When switching to another directory before the current one has finished loading, the ongoing loading process should be stopped and the new directory should start loading. The server should not crash in this situation.

Context

Where has the issue been observed:

• Android
• Chrome
• iOS
• Linux
• macOS
• Web
• Windows

Closing Criteria

Checklist for closing the issue:

• No errors from make prep
• All tests pass make qtest
• When switching to another directory before the current one has finished loading, the ongoing loading process should be stopped and the new directory should start loading.
• The server should not crash in the situation above.

[jesscmoore]

This is likely documented in the Solid repo and raised in their forums. Looking there might help us characterise the problem and how to manage jobs to avoid triggering the problem. Jesse encouraged us to contribute our observations (learnings/issues) to that working group https://www.w3.org/groups/cg/solid/ - using repo. There are also the v late thu night mtgs.

[cdawei]

The logs (from CSS-v7.1.0) seem to indicate a locking issue:

Process is halting due to an uncaughtException with error Cannot read properties of undefined (reading 'updateTimeout')
/opt/solid/.nvm/versions/node/v20.15.1/lib/node_modules/@solid/community-server/node_modules/proper-lockfile/lib/lockfile.js:104
    if (lock.updateTimeout) {
             ^

TypeError: Cannot read properties of undefined (reading 'updateTimeout')
    at updateLock (/opt/solid/.nvm/versions/node/v20.15.1/lib/node_modules/@solid/community-server/node_modules/proper-lockfile/lib/lockfile.js:104:14)
    at /opt/solid/.nvm/versions/node/v20.15.1/lib/node_modules/@solid/community-server/node_modules/proper-lockfile/lib/lockfile.js:167:17
    at FSReqCallback.oncomplete (node:fs:187:23)

Node.js v20.15.1

[tonypioneer]

This issue has been fixed in tony/153_refactor_file_browsing_code.

In this branch, I fixed two issues related to this ticket.

Issue 1: Double slashes (//) in GET request paths

Root cause: When currentPath is an empty string (i.e. the POD root directory):

• '$currentPath/$dir' produces '/$dir' (leading slash)
• [currentPath, fileName].join('/') produces '/fileName'

These paths with leading slashes are passed to getDirUrl(). In _getResourceUrl, wId.replaceAll(profCard, '/$dir') then generates https://pods.solidcommunity.au/tchen//$dir/ (double slashes).

Fix: Replaced all path concatenation with PathUtils.combine(), which internally calls PathUtils.normalise() to remove leading/trailing slashes and consecutive slashes.

Issue 2: Excessive REST calls

Original flow: refreshFiles() performed N+2 REST calls:

• getResourcesInContainer() — 1 call
• getDirectoryCounts() — N calls (1 per subdirectory)
• getFiles() internally called getResourcesInContainer() again — 1 call (duplicate)

After modification:

• Removed duplicate calls: The getFiles() signature was changed to accept a prefetched List<String> fileUrls, so it no longer calls getResourcesInContainer() internally.
• Lazy loading for directory counts: Initial rendering now requires only 1 REST call (+ a HEAD request per file to obtain lastModified). Subdirectory file counts are loaded asynchronously in the background. The UI first shows a small loading spinner and automatically updates with the actual numbers once completed (this step is critical to fixing this issue, and this step also increases the file list loading speed).
• Prevent stale results: _loadDirectoryCountsInBackground() records the path at request time and discards results if the user has already navigated elsewhere.