I haven't really had any issues in a while.

I don't want to install it on cluster hosts, see T7785.

I believe this should now be fixed in HEAD. Please let us know if you encounter further issues.

I believe this should now be fixed in HEAD. Please let us know if you encounter further issues.

I decommissioned the old .org host. I'll give the old secure host another week or so since we did hit a couple minor config things where it was useful to double-check that there was a config change.

If you have a chance, can you pull a Services/Profile on this too? Round trip time on this install is <50ms.

If files had a directory structure on top of them instead, would that solve this problem?

Can you walk me through this? Why are you updating a revision after marking a bunch of things "Done", but not wanting the "Done" to publish?

I think this is covered, now?

Seems fixed.

This seems to be stable now, I don't immediately see any more ridiculously dumb slow stuff in the /feed/ profile. Remarkup handle fetches are still a bit loopy but that's a topic for another task.

This accurately reflects the user's action. We generally try to faithfully do what the user says, not what we think they mean. It is much more confusing if Phabricator ignores your edit without explanation than if it faithfully reflects an edit exactly as you made it, by accident.

We aren't interested in bringing this upstream.

I believe there are currently no "bad" versions of arc against HEAD which don't already tell users to upgrade -- some recent versions of arc had issues with recent versions of phabricator, but all recent versions of arc work correctly with HEAD. Although this presumably won't always hold, I think the miss rate here is so low that I can't imagine building anything in advance of the stuff connected to T5055.

There are no other steps to do.

If I were to guess, I'd say that this was caused by T8095.

Yep, I believe so.

This is probably fixed by rPd5e4d960.

Thanks.

Does it repro if you upgrade arc past rARC29839e8?

What hashes are arcanist and phabricator at?

This isn't something we're interested in pursuing in the upstream. You could add a Custom Field for it locally.

The exception is fixed; there's now a policy/filtering-related hang.

It seems counterintuitive to me.

Here's the trace. I don't think this is a dupe.

I don’t want to change my project’s established conventions and clutter my git logs because arc wants to scatter droppings all over my commit messages.

do not necessarily reflect reality by the time it actually gets committed.

For example, the project might handle testing differently, and not want the ‘Test Plan’ section.

This behavior seems fairly expected/reasonable to me.

This is a very low priority for the upstream.

Please see Planning and Contributing Code. See also T8227.

It deletes branches in the remote, and does not necessarily have (or otherwise currently need) permission to push to the staging repository.

Mentioning it is probably OK, hitting it just dumps the server into a death spiral for that process until it times out so I didn't want 20 people clicking it. :)