Switching songs is being treated as an error?

[michalsieron]

Sometimes when I switch song its being logged as an error (although more correct would be saying "almost everytime")
Example:

I don't know if it is something you can fix, because it seems that error originates from rocket crate (as indicated by path), but maybe you can catch it somehow.
Btw. I get similar error on linux (ogarcia/docker-polaris), but it is a little bit different:

Polaris is running on Windows 10 19041.450.
Accessed on Firefox 79.0

[michalsieron]

I feel that it is related to this one so I will post it as a comment here rather than new issue.

1. Log in
2. Go anywhere in directory tree (or just stay at top level)
3. Queue anything (by clicking on song, dragging album, clicking "Queue all")

And now on Windows an error is logged. The same one as in this issue.
But on linux (docker) there is a different error:

This only happens on fresh login (so clear cookies, login and then follow steps)

[michalsieron]

And that I have no idea if it is related, but here it is:
I experienced it only on linux (docker), but sometimes I could get Polaris to state where doing anything: from changing position in directory, through getting random albums, to accessing tab in settings required changing song in queue.
Yes, changing song in queue....
It seemed like requests were waiting for response and were getting it only when song change was happening (at least that's what Network tab in Firefox DevTools seemed to say)

[agersant]

I have noticed similar errors before and spent a lot of time investigating them. Some of the related issues are rwf2/Rocket#1023, rwf2/Rocket#1254, and possibly rwf2/Rocket#580. The common theme is that these errors are bugs in old versions of Hyper (the HTTP library used by Rocket). The bugs in Hyper were fixed a long time ago, but there isn't a release of Rocket with an up to date Hyper (yet). The waiting room for Rocket 0.5 which fixes all this is here.

I did implement the keep-alive suggestion which is mentioned in some of the tickets above, but did not observe a significant difference in behavior. I believe @lnicola never ran into this, which means running behind a nginx reverse proxy (as he does AFAIK) may be a better workaround.

[vvrein]

Same thing for me, and I don't think that this is an something about meanfull error, since it didn't break anything.

I think this is because client opens new connection for new track, and possibly don't wait for connection to be closed or forcelly closes connection, in time when server is pushing track or was hanging on connection.

But I wasn't dig into the problem, just saw this error in log.

[lnicola]

I would ignore it. The browser closes the connection (which is the graceful way to abort a request) so the server gets a write error. Most web servers don't log these by default, but Rocket seems to do. I don't think this is really an issue.

[agersant]

Fixed in release 0.13