dart-lang
500 errors for `*.ddc.js.errors` files prevents console logging of compilation errors
This looks like a side-effect of changing canRead to fail for "failed" assets.
We fail the build step on compilation errors which means that we can't read the errors files any longer.
@natebosch do you remember why we decided to refuse to serve these files? I am not sure if the correct fix should just be to enable reading them again or something else.
Another solution here could be removing the explicit .errors file, and instead returning a response body with the original request, which contains the severe logs for that request? That should be doable since we now serialize the severe logs to disk.
@natebosch do you remember why we decided to refuse to serve these files? I am not sure if the correct fix should just be to enable reading them again or something else.
Yes, we don't allow serving outputs from failed actions and don't distinguish this output from any other.
I think we did discuss removing .errors and including the logged error in the HTTP response. With the cached error reporting I think we have what we need for that.
This looks pretty reasonable, I may add something to the FinalizedAssetReader to return the failure reasons (the asset handling code doesn't deal with asset graphs directly today, just a reader, better to keep it that way).
It'll be a bit tricky. FinalizedAssetReader has a lifetime that spans builds, FailureReporter is per build IIRC.
We could do something like we do with OptionalOutputTracker which gets reset() in between builds maybe?
I think we've struggled in the past to keep the lifecycles and communication pathways of these various objects well delineated...
The FailureReporter does span builds - but actually in this case I can even create an entirely new one - it isn't specifically tied to a build at all it just knows where to look for error logs. The only special thing it needs is an asset graph (which spans builds).
It also has some functionality to know if it has already reported an error (and it can clear out that state), but for this functionality I don't care about that (I always want to return the error logs with the request).