Some pretty good discussion here:
https://secure.phabricator.com/D8040#4
Currently, in Diffusion, when changes and files are too large we don't fail very gracefully. Instead, we should degrade gradually.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | epriestley | T4474 Improve Diffusion behavior for large files and changesets | ||
| Invalid | epriestley | T3141 Improve general stability/sanity of Diffusion file content queries |
Event Timeline
Comment Actions
See also T8597. Two specific areas for improvement:
Return Filesizes: For large files, in VCSes where we can reasonably do so, it would be desirable to return the actual filesize when failing because of the byte limit. We could render a specific error message ("This file is 128MB") instead of a more generic one ("This file is more than 4MB.").
Stream Large Files: We can have the API call push file data into the filestore and return a file PHID instead of returning the actual content. Then we can support arbitrarily large files without streaming them. Getting stuff like cache semantics for enormous files correct is tricky in this case, though, and we also need to be able to push data through the chunk/allocate workflow from within Conduit.
Comment Actions
I think all of this is fixed at HEAD.
Downloading huge binaries might still not always work but I think the need for this is rare and I'd like to see installs hit it and have a reasonable use case for it other than T1816 before pursuing it.
(There are a handful of followups kicking around elsewhere, like T8407, to make minor improvements to behaviors here.)