Debug mode sometimes retrieves incomplete files

[peacememories]

Hi, and thanks for developing this invaluable tool :)

I've got a bit of a problem. I'm serving the content of the embedded folder via actix-web, and running a parcel watch job for frontend development. This frontend tooling has autoreloading, so when the watch job builds a new version of my frontend the page gets reloaded. This almost always results in only half of the javascript file getting served and the reload aborting because of it.

I don't know how rust-embed works internally, but I'm assuming this is because rust-embed reads the file at a time where it's not done being written?

[AzureMarker]

The debug implementation doesn't use anything special, just read_to_end:
https://github.com/pyros2097/rust-embed/blob/0939ff03a20a378978d1a62852220bfd188d28fb/impl/src/lib.rs#L32-L37

Perhaps Parcel is writing the file in chunks, and rust-embed is reading in between chunks?

[peacememories]

That might be the case. I'm probably going to ask there too. Any idea what I could do on this end? 😅

[pyrossh]

@peacememories does it work with other static file servers like node-static or parcel's own static file server. If it does then it could be an issue with rust-embed.
As for now we don't know the reason why the request is aborted because the errors are swallowed up here,
https://github.com/pyros2097/rust-embed/blob/0939ff03a20a378978d1a62852220bfd188d28fb/impl/src/lib.rs#L32-L37

Maybe adding a log or print here would help out to find the root cause of the issue.

[peacememories]

Sorry for the late reply, holidays tend to screw with my schedule^^
The same frontend has so far worked with a similar go-based approach (that is actually the main project, I'm trying to proof-of-concept a Rust version), as well as with parcel's own server. This has led me to believe that something in the interaction between parcel and rust-embed causes the issue. I've not had the time to add the log messages you mentioned, but I'll try to get to that today :)

[peacememories]

Correction, it seems our go-based webserver has the same problem.