I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

@chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

Sorry, apparently after running arc upgrade it no longer times out (although it does take a long time).

In T11699#195930, @chad wrote:

The error log says July

Server

• rP38b10f05a224d29c723c033dec0820f977aa8026
• rARC483e985d08d279816708a9e755de8e5c3586d3ba
• rPHU1a0371a2247a256d1e6e44d4f348adc2750a9788

Here are some query traces from XHProf:

How can I reproduce this locally? See Providing Reproduction Steps for help on providing reproduction steps.

To accept this report, we need reproduction instructions we can follow to reproduce the issue locally. See Providing Reproduction Steps for details.

I think this is entirely reasonable.

To actually add a remarkup rule, the basics are simple:

I think this didn't actually get handled in T10262, but should be doable now.

Unicode has a page of heiroglyphs but they don't seem to be supported yet on OSX.

This is probably 5 minutes of work, I am just incredibly unreliable.

Actually, I don't think we can really style the numbers of a numbered list independently of the rest of the list. They aren't directly addressable with CSS and the approaches I've found for doing it rely on using counter(...), which I think is unreasonably complex for this use case:

I can't reproduce this. Here's a diff with a new file:

Ah! Thanks, we'll get this fixed.

See Contributing Bug Reports if this is intended to be a bug report.

Does raising max_connections in /etc/my.cnf (or similar) and restarting MySQL resolve this?

GitHub also does this:

We made one change recently (T11672) but that should cause us to use fewer connections.

Please see Contributing Feature Requests for help filing feature requests. Thanks!

This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.

I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!

Presuming resolved by D16584. Thanks!

I've banged on this a reasonable amount locally without issues and the originating instance reports that this seems to have calmed things down in production with these patches, so it seems like this pretty much just worked.

There's a bunch of other Herald stuff we already do for this field so I'm just undoing the change from D14766, at least until someone complains that this field type isn't using the search logic they expect.

Yeah, go ahead and submit a patch. Thanks!

I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.

To fix:

We don't normally accept bug reports on prototype applications (see Prototype) but this is a one-line fix.

To fix this:

This isn't a bug in Phabricator, then. Please review Contributing Bug Reports and Support Resources carefully for details on what we provide support with.

On the cache:

I think this is the CSS that tries to cut off the titles interacting weirdly with other table CSS.

I believed this was semi-intentional, although the downstream report suggests it worked at one point, so maybe I just made a mistake.

In this case, use the AphrontWriteGuard::beginScopedUnguardedWrites() method to surround the block -- you can grep for usage, but it will look like this:

All queues have emptied, and repo002 is back in a healthy range again:

rP9329e6a12d9f improved the rate at which the Herald queue is draining by approximately 10x.

I've moved the largest instance from repo002 to a new empty shard, which has put both shards into fairly reasonable range. Queues still aren't draining as quickly as I'd like/expect.

I moved the largest instance from shard 002 to shard 006. This took about 35 minutes, most of which was backup/transfer time. I hit a couple of minor issues, but things appear to have worked properly overall.

I migrated a test instance, which appears to have worked properly. I'm going to run though things again, then move a large instance off repo002.

• Suspend the instance: Admin → Instance → Manage Instance → Suspend Instance
• Stop the daemons:

I've provisioned and deployed a new shard, but not yet opened it for allocations. I'm going to launch and then migrate a test instance next.

I let the queues drain for a bit overnight. One of the large queues is down from ~16K items to ~12K items in the last 8 hours, but I don't want to just let this sit for 24 hours to "resolve" it. I'm going to look at moving instances across shards instead, which is a capability we need to automate eventually anyway.

Is this reproducible using fields available in the upstream? How can I reproduce this issue against a clean, vanilla, up-to-date copy of Phabricator with no custom code?

Where is "Platform--MUST-->" coming from? That isn't a field we provide in the upstream.

Looking at improving the raw performance of bin/repository update, one fixable issue is that we run git for-each-ref three times:

I also identified an instance with a bad HTTP hook which had managed to queue up 8,000 tasks in the queue. These already have scaling backoffs and likely didn't contribute a meaningful amount of load, but we could perhaps find a more graceful approach to handling bad webhook URIs during T11330.

I disabled the keys of the user running 30 clones/minute and notified the instance administrator. This appeared to create some headroom; I reverted the daemon pool size limits to the default and we're draining the queues at a somewhat more reasonable pace now.

@swisspol, that's what this refers to ("From T11666"):