Can you do this to get a stack trace?

• Set debug.time-limit to 5 in your config (you can do this in the Config application).
• Load the page which exhibits the problem.
• If the stars align, it should exit after 5 seconds with a more useful stack trace.
• Paste that here.
• (Then, delete debug.time-limit from your config to disable this debug mode.)

That should help us hunt this down a little more quickly.

Request aborted by debug time limit after 5 seconds.

STACK TRACE
utf8.php:45 PhabricatorStartup->onDebugTick()
DarkConsoleCore.php:130 phutil_utf8ize()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:126 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:58 DarkConsoleCore->sanitizeForJSON()
DarkConsoleCore.php:110 DarkConsoleCore->getKey()
PhabricatorStandardPageView.php:332 DarkConsoleCore->render()
AphrontPageView.php:76 PhabricatorStandardPageView->willSendResponse()
PhabricatorController.php:419 AphrontPageView->render()
AphrontApplicationConfiguration.php:234 PhabricatorController->didProcessRequest()
AphrontApplicationConfiguration.php:140 AphrontApplicationConfiguration->processRequest()
index.php:21 AphrontApplicationConfiguration->runHTTPRequest()

Actually, this doesn't look like a bug, but a settings issue. Though it should probably fail more gracefully.

"local-disk PhabricatorLocalDiskFileStorageEngine" is set to 8M.

I don't immediately see how to change that value, but it can be tracked down...

Two fixes here:

• D13347: If we have a huge amount of data from a service call, we no longer try to display all of it in DarkConsole; doing so is useless and this was previously very slow because of utf8 sanitization.
• D13348: We now fail more aggressively on large files, producing a reasonable error and a usable page.

These things could be improved, but are more involved:

• We could determine the filesize of large files without downloading them, but currently do not. This would let us display a more specific message about the size of files ("This file is 215MB", instead of "This file is larger than 4MB").
• We could support streaming large files out of the VCS, but currently do not. Pulling the file may involve a service call over the API, and the API doesn't currently support streaming. We could reframe the API call to have the server on the far end push the data into the filestore and give us back the PHID, which is reasonable, and would let us stream the file from the frontend, but this is a moderate amount of work and potentially a breaking API change. For now, use git from the CLI to access files larger than 4MB.

I'll note these specifically in T4474, but don't plan to pursue them in the near term.

I think this is now fixed (in the sense of "not broken anymore", not in the sense of "working as nicely as it possibly could"). Let me know if that's not the case.

Ok, so that definitely fixed the error. Now it presents the page correctly, but notes:

"This file is larger than 4194304 byte(s), and too large to display in the web UI."

It doesn't have a link for a raw download though. I understand it not displaying it/rendering it, but by "too large to display" does that mean it is too large for a raw file link?

So, in sum, the error is gone, and it looks better, but the raw file still can't be downloaded, afaict. Thx!

This error is probably similar, at this URL:

https://code.alephobjects.com/diffusion/OM/browse/master/AOOM.pdf;ecf68331ff60b8adb876ca8e018334c55d5c2e6f?view=raw&ref=master%2FAOOM.pdf%3Becf68331ff60b8adb876ca8e018334c55d5c2e6f&whitespace=show-all

To reproduce:

1. Go to https://code.alephobjects.com/diffusion/OM/change/master/AOOM.pdf

2. Click "View Options"

3. Click "Show Raw file right"

and it bugs out.