@aleb, if you like to continue discussion of this please use the appropriate channels, as @chad suggested above (at the time, they were Conpherence and Ponder, but the appropriate channel is now the community forum -- see: Discourse).

The error truncating behavior affects also Diffusion > R > Status, where only part of the stderr is shown, making it impossible to debug the problem without hacking Phabricator:

ab@phabricator-1-vm:/opt/bitnami$ diff apps/phabricator/libphutil/src/future/exec/CommandException.php.original apps/phabricator/libphutil/src/future/exec/CommandException.php
59c59
<     $limit = 1000;
---
>     $limit = 1000000000;

T12956 has another situation where letting MenuItem generate 2+ items may be bad: we want to let a menu item steal the selection, but it's muddy to implement if each MenuItem can return several actual views.

Thanks for the detailed response, I certainly didn't expect it.

I believe the location of the OOM is a little misleading -- the real problem is loadFileData(). This returns the entire file as a string, and will thus:

The new rules on reports are still in flux a bit and extra-muddy for Community members, but I'd generally like to move to a "report + review" model for community reports, something like we currently have for code review. So the general idea is that your bug needs someone to review it and agree with it (e.g., reproduce a bug, or agree that a feature request is a brilliant new idea that makes sense and would be appropriate for the upstream and completely describes a reasonable, generally-experienced root problem) before it comes upstream.

I think this is a real bug. Here's a more complete example of what's going wrong, why it's wrong, and how to reproduce it.

I would open to accepting this as a bug report if I felt it was deliberately designed to work the way you expect, but was not (like a regression). Or if information was presented that all other repository viewers do it this way. Otherwise I think it's more 'nitpick' or 'feature request'. A cursory look at GitHub, seems they show the full diff as well: https://github.com/phacility/phabricator/commit/5c1e4488dedafda08684b33a8a4786cf687d2811

In T12959#230805, @chad wrote:

In general are you aware we no longer take bug reports or feature requests here?

In general are you aware we no longer take bug reports or feature requests here?

In T12959#230799, @chad wrote:

What does "mysterious" mean.

What does "mysterious" mean.

I can confirm this.

Doesn't seem to reproduce any more - I have no issue importing from another milestone. Presumed fixed, but if not, please reopen with more detailed reproduction steps.

Just launched a test instancepoo and everything seems fine.

I wonder if this OOM error can also be hit in other workflow though, given that it seems to occur in PhabricatorFileStorageEngine::getRawFileDataIterator.

Yep, agreed that the re-targeted proposal is a better solution... I had just assumed that this was a documentation oversight.

The plan forward here is to correct the text. I will follow up with you on Discourse.

We require the "a revision's reviewers can always..." behavior. Please implement it instead of changing the text.

D7150 added this text ("a revision's reviewers can always...") and I said it "wasn't true but would be soon", but never made it true.

fwiw, I can't reproduce this on OSX chrome any more. going to go test windows in german.... wish me glück.

I retargeted this; I think the proposed solution is not the best solution we can find to the problem.

We should probably just remove this workflow, it's not clear to me that there's ever any reason for anyone to run bin/files purge in the modern codebase.

I'm seeing these errors failing regularly:

The simplest way to approach this is probably to do double writes: start writing the new tables, switch readers over, stop writing the old tables.

Let me know if that diff works.

I honestly can't get the cool looking macos dropdown on firefox no matter what I try.

Per above, this is not a bug.

This appears to lack reproduction steps, so we can't move forward.

What is the network speed of transferring a similar file (e.g., a 400MB file from /dev/urandom) via ssh cat <file>?

Per above, the decision to color the default state is explicit so this is likely just a design tradeoff in the short term. I can test things locally if you want to keep fishing.

There's probably no reason for us to have color: ... on the <select />

While checking again I noticed:

1. Explicitly setting the color: to #000 changes Last-Monday → Mid-April
2. Removing/unchecking the color: in the web inspector doesn't have any effect, it looks like because <select /> elements are inheriting that style in two ways. Removing/unchecking from both definitions/rules will change it Last-Monday → Mid-April

Is this the current status here?

I'm just going to merge this into T10448.

This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.

I suspect this is actually more like: actions on Ponder answers are not covered by the "Ponder Questions" email preferences, because a "Ponder Answer" is not the same type of object as a "Ponder Question".

Closing for now, it's reasonable to post populate the table if we do decide we need the information. I'll note it on T5505

No worries, and appreciate the help.

Fair enough; I'll stop bothering you now. D18280 looks good to me.

I don't know and I've spent way too much time here already.

In T12933#230136, @chad wrote:

I see no way of reconstructing the rows.

I see no way of reconstructing the rows. It appears versioning never worked (and nor do we surface it anywhere). We can add a migration to fix the current times though.

I may be mistaken, but it seems to me that D18280 will fix the problem only for new edits, made after that revision is applied. Is that right?

Seems a reasonable place to start. I'll look at this soon.

In T12933#230063, @epriestley wrote:

The creation date and modification date of a body should always be the same, like they are for a Phriction document body.

There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think I have a fix but can't find the command line trick you showed me to test it.

In case it helps: I think D13982 introduced the code being edited by D18253. But it sounds like some other code isn't behaving the way you were expecting it would.

I think you're innocent and that it never worked but I only looked at it for like 2 minutes.

I should be able to bisect this if I brokened it.

There may be a bug with the body versioning (maybe it got broken by accident when we swapped to ModularTransactions, or maybe it never worked), but if there is we should fix that bug. The creation date and modification date of a body should always be the same, like they are for a Phriction document body.