Version: 0.22.4
Platform: ARM64 (RPI4)

@jpdillingham this doesn't appear to fix the issue for me of not being able to fetch directory contents. Before this merge there was an error visible in the log:

Error handling peer message: FolderContentsResponse fr
om sant0.3. (181.30.23.66:59968); Cannot convert type 'System.Threadi
ng.Tasks.TaskCompletionSource<System.Collections.Generic.IEnumerable<
Soulseek.Directory>>' to 'System.Threading.Tasks.TaskCompletionSource
<System.Collections.Generic.IReadOnlyCollection<Soulseek.Directory>>

Now this error doesn't appear anymore with the new release, but the webinterface shows this error dialog instead:

The directory contents are then not retrieved.

@litemotiv can you try doing a hard refresh on your browser? shift+f5. You might have old application code cached.

If that doesn't fix it can you please open the console (f12) and screenshot/paste any errors you see?

@jpdillingham the error appears to persist after hard refreshing and restarting the browser (Firefox 137). This is the output in the console:

TypeError: i is undefined
    getFullDirectory Response.jsx:94
    onClick Response.jsx:176
    React 12
    unstable_runWithPriority scheduler.production.min.js:19
    React 3
Response.jsx:105:14
    getFullDirectory Response.jsx:105
    onClick Response.jsx:176
    React 12
    unstable_runWithPriority scheduler.production.min.js:19
    React 3

I added some additional error handling that should solve the exact problem you're having, but I'm somewhat concerned that we're getting no results back when requesting a directory. I don't know of any clients except perhaps early builds of slskd that would do that.

#1328 is going to go out to the canary build in 20-30 minutes, I'd appreciate if you could pull that and see if that changes anything.

Are you getting this for a specific user, or all users?

Here's the build: https://github.com/slskd/slskd/actions/runs/14433060140. The canary image will be pushed to docker hub; if you're running from the binaries you can get them out of the artifacts from this build (unless that's restricted to maintainers only)

I notice that the results themselves do appear to be fetched okay:

So it seems it's mainly the iterating through the received result set that is failing.

I'm currently using the binary version btw.

I added some additional error handling that should solve the exact problem you're having, but I'm somewhat concerned that we're getting no results back when requesting a directory. I don't know of any clients except perhaps early builds of slskd that would do that.

The only client I'm aware of is Soulseek NS, which doesn't understand paths encoded to UTF-8 sometimes. It will send an empty response until you encode the folder path to latin-1 (ISO-8859-1): https://github.com/nicotine-plus/nicotine-plus/blob/729710cc9a1e5169c868435a3f9073c16f13ef2c/pynicotine/downloads.py#L1001-L1005

Edit: Another case is SoulseekQt, which doesn't send any response at all for folder content requests on private folders.

Might not be related to the issue, but it's useful for future reference.

Update: directory fetching works well for me using the canary build

Thanks for the confirmation @litemotiv; 0.22.5 is on its way now

I still get this error with 0.22.5 when pressing "Get full directory contents". I've done a hard reset of Firefox.

@MitraMai you're getting the i is undefined popup?

If so could you please enable debugging and try fetching the same directory from the same user, and see if any errors are shown?

Yup, that's the message I get. And it's still present after turning on debug-mode

@MitraMai I created #1365 to track this