In the refcursor table, our current autoincrement is at 312,036,016. This is only 7% of the way to int unsigned, but the fact that we've made it to 7% in 18 months might suggest that column should be BIGINT, unless there are performance impacts of that.

See PHI11. This has material impact when using PhabricatorRepositoryRefCursorQuery to query landing targets, and likely impacts the logic in DifferentialRevisionOperationController.

A customer is hitting an issue where pushes to staging areas do not push LFS objects. I'd guess this is an LFS upstream problem based on a hazy recollection of events here.

What if they're on the page, is that notification annoying? I love click that little guy.

+1, we've also had a handful of users request this as a per-user preference.

We've also had a request for this (disabling the in-application popups) at #dropbox, as a per-user preference.

Synchronously in the request. I'll look at adding logging.

If you go through the process manually with the web UI, are the versions OK after initial creation? After adding an observed URI?

This is an issue specific to the repository names containing hyphens. The code is already calling calling the correct sort functions.

I created these repositories:

So I'm not immediately able to reproduce this. Some possible questions:

I used this parameter bundle to create a repository:

I'm attempting to reproduce this from the web UI first. I created a new repository, and get 0 versions as expected:

A related issue surfaced recently. Actual use case (forensically reconstructed):

Yeah -- the workflow from the Maniphest side dumps all the values into inputs in the body and does a POST, I believe.

Interestingly I worked around the issue by doing the batch edit from the Maniphest search UI which is passing the selected tasks an HTTP body instead of a URL query I guess?

@swisspol hit a variant of this with 1,172 tasks bumping up against an Apache URL limit in the Phacility cluster when editing from a workboard column.

Two questions pick at me:

1. Which editor did the user use to add the ZWS in? Any editor I remember does something to warn you about it.
2. Why are there Unicode characters for "goat" (🐐) and for "cooked rice" (🍚)?

me too but not everyone is on our level

FWIW I only code via copy/paste.

• T2495: Improve whitespace expansion of tab literals is somewhat adjacent here.
• T11632: Display invisible characters on erroneous user input is a little related: if we generate canonical lists of "invisible" characters in UTF8, they should probably be shared by all three of: the code that detects when input in forms is invalid because of invisibles; the future UTF8-aware invisible mode; and the UTF8 text linting mode described in T11150.

Per above, these are already detected by the Text linter:

This is now deployed here, to secure.

@amckinley, I'd like to try to do this as part of T12798. Here's my rough understanding of what we need to do:

D18069 appears to fix this, but I want to understand where it blames to and possibly pursue a more graceful fix since D18069 feels a little flimsy.

Arguments against:

It's possible that didn't get everything, but yell if you hit anything else and we can shovel on some more test cases. Thanks for the report!

@epriestley yes, the tested owner packages were both weak dominion. Sorry for not mentioning that earlier. You've explained the issue perfectly as far as I can tell. The changes you have planned make a lot more sense than the current behavior and should fix the issues we were seeing. Thank you!

@lvital, I can only reproduce this if use "Weak Dominion". Is that the case in your example, too?

I had indeed implemented precisely that herald rule once I realized that these diffs were being created without repository info attached. I also added repository.callsign to /etc/arcconfig to eliminate the problem going forward.

We've seen a couple of flavors of this from @swisspol, too. Although the symptom there is a little different (not a policy issue, exactly), the root cause is mostly similar. In particular, we saw:

Here's an example of the old style:

In T12234#211222, @epriestley wrote:

From a technical standpoint, we did not record these relationships in a normalized way prior to D16196 (June 2016, about 7 months ago) -- they only existed in the transaction log, and we just wrote a "close", extra_data="as duplicate of X" transaction that can't be queried efficiently.

Anyways, let's just go with "See all" in the header for now.

I'm also not sure how that works with pagination, like, do you update the URL so people can send links?

But that sounds like a lot of work.

Basically what I'd like is something that auto-pulls maybe 5 times, then just makes you click a button thereafter. That solves the footer issue, makes it nicer for people who only want 2-3 more pages, and then the edge case of "no really I want to keep reading past 500 results" have to click a button.

Let me marinate on it.

Sure, we can do that too.

Isn't auto-scroll with lots of JavaScript the right answer?

Ah, that makes sense. If there's some "good enough" way to get a button/link into these things today I'm happy to drop that in place while I'm in here, but we can just leave it for fiddling later too.

I don't think the current feed UI looks good in blue header, which is why I haven't moved it over. I'd need to fiddle with feed-view

@chad, I'd ideally like to put a "view more" on the feed on the project page so that the original issue here (wanting to page back in history) is easier to solve. This is what it looks like right now:

That could work too. Perhaps a box of donuts instead though.

I think that should fix things, but yell if I missed anything or made it worse or whatever. Thanks for the report!

Another approach might be to do T11934 first, and then implement this as /accept-magnainmously. This would be very hard to discover, but it's possible that ~10 users worldwide are meaningfully impacted and I could send them each a nice fruit basket with a card explaining the feature.

In T12758#225035, @epriestley wrote:

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

I'm hesitant to pursue this today because I want to be cautious about adding too many actions, and I think other changes may add more valuable actions ("Accept Next Update", draft-state actions from T2543, etc). This action would probably be fine today in isolation since the dropdown doesn't feel too cluttered right now, but if we added it I think it might be the least valuable / least frequently used action in a list that is starting to look pretty bloated six months from now.

(I think it's also somewhat hard to pick a 2-3 word phrase which clearly describes how this potential action differs from "Accept" -- I can't come up with anything good offhand.)

Another solution I could imagine is to add a distinct action, other than "Accept", which works like the old "Accept" did, i.e. "Accept for all reviewers I have authority to accept for", say "Accept Magnanimously".

Yep, those repro steps look right to me.

FWIW, a check-all box is what we had in mind.