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.

The community forum is a better place for this discussion. You may or may not receive help there, but we're no longer providing general Phabricator support here in the upstream (nor have we for a long time).

In T12959#230805, @chad wrote:

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

In T12959#230799, @chad wrote:

What does "mysterious" mean.

Named queries will get a new flag like isGlobal

I'm not proposing that, no. Here's exactly what I'm proposing:

I wasn't planning to change the behavior of the dropdown, except that it would begin listing personal filters followed by global/default filters under "Saved Queries".

Where's the other conversation?

I think we should still default search the top item.

I don't think this is resolved, just an unclear report. To access this screen:

And one more, also for Kotlin.

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.

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.

Happy to take a look if you found a reasonable way to get access to $request. If you're reading $_REQUEST['__path__'] directly or something though the eventual upstream version probably won't look too similar.

PHI27 is likely adjacent here.

I'm just going to merge this into T5258. There are two separate issues here:

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

In T12950#230520, @chad wrote:

Why did they need regenerating in the first place?

See Planning for information on progress and priorities.

This is an unusually low-tech solution but I can't think of any reasons why it won't work.

Is there any reason that the rule "if any menu items have the same link target as the request URI, highlight the first one" wouldn't work?

• What's the root problem?
• Why can't they use links?
• How is this different from T12374?

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.

Have you enabled diffusion.allow-http-auth?

Just keeping an eye on this: growth on these shards is slow and both are still below the 80% caution threshold, so I'm punting this for another week.

I'm seeing these errors failing regularly:

I've got a reproduction case for this now: https://secure.phabricator.com/differential/diff/44008/

Most browsers can only give us a timezone offset, like "UTC-7", not a locale name like "America/Los_Angeles". We already attempt to read this value (D15962, T3025#176547) but when I wrote that stuff it was only available in Chrome and not necessarily reliable. We do try to guess the default zone selection based on the information we get from the browser, but currently ask the user to confirm it in all cases.

@kfsone Are you aware of arc diff --only (briefly mentioned above -- "just generate a diff to look at in the web UI, without other slow/complicated steps")? How do you picture arc selfreview differing from arc diff --only?

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.

This could also just go on the existing page at the bottom. We tell people to copy/paste it when submitting bug reports, but it's probably fine if they're including more information, especially since there is a nice walled garden moat around my personally having to deal with it.