Media uploads block forever when provided and actual media sizes differ #2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When a user uploads some piece of media, the Titan URL requires a
sizecomponent to be provided, which is the size of the file in bytes. When the providedsizeand the file's actual size are the same, everything works as expected, but when they differ, reading from the port will block forever.It seems the port doesn't actually return
eof-object?when the media's done uploading like I'd expect it to, so as far as the read function is concerned, the client's implying that it still intends to send more data. My best guess at the moment is that this has something to do with the fact that the port is wrapped in a TLS layer. I'm not sure whether you're even supposed to be able to geteof-object?when it literally isn't the end of the file (it still has to do more TLS stuff after the data we actually care for).In any case, I have zero clue how to solve this issue. The best thing I can currently think of is to have some sort of timeout, so that it just kills itself if it takes too long, but that's a really stupid bandage fix, and I'd prefer to actually solve the core issue, if possible.