I expect the general shape of the code to survive, but a lot of the particulars to churn. There are lot of issues with state handling, error handling, locks, which things are responsible for what, etc., right now.

Yeah, I think that's probably the cleanest way to approach this today. That mostly works around the management mess, too.

I left this open because I think the information in the description is useful for us in eventually crafting setup checks and possibly including in the documentation.

The described behavior is working as expected, I think.

Now done:

I think changing the proposed behavior (making subscribers inherited in some form) is possibly reasonable, in that this is probably a common desire, although it seems like users might also reasonably want to subscribe to /x/ without subscribing to /x/*. We could let you "subscribe (this page only)" vs "subscribe (this page and all sub-pages)" but Subscriptions would need to expand substantially to accommodate that and there are no other use cases in other applications that I can think of (except sort-of Projects).

Another workaround involves working with remote offices. The reviewer prefer not to block the author, so they resign as a reviewer and suggest someone from the author’s office as reviewer. This has two big issues. First, the commit message will not have the original reviewer on it, so if there’s a prod issue, or someone is just going through git log for context, they wouldn’t see who the actual reviewer was. Second, the diff doesn’t appear in the author’s queue but in the new reviewer’s queue. And the next action should be taken by the author.

This is UI oddness, you're doing everything right.

The core of this should work now. These things aren't happening yet:

Whoops, fixed. Thanks.

Just jotting these down here to make sure they don't get lost:

It looks like viewerprojects(), specifically, isn't included in these sources at HEAD.

Are you at HEAD / does this problem still exist on this install?

Given that it looks like you were able to apply a patch locally in T8654 which was available in HEAD in June, I think your client was out of date.

No one should need to follow those instructions, because this patch has been in HEAD since late June.

Can you show me the output of arc version?

One caveat to the above is that loading src/extensions/ may trigger loads of other code through autoloading extended classes. So I'd expect one of three outcomes from the PHUTIL_DISABLE_RUNTIME_EXTENSIONS test:

Interesting. That "load libraries" step is much slower than I'd expect; we see ~5-10ms on this host.

When we generate your first real invoice, add language telling users they can just not pay it if they didn't want to continue service and just forgot to cancel.

Are you telling me the arcanist manpage content depends on the installed plugins ?

Is there a chance to have a man page for arcanist anytime soon?

(It appears that this is specific to the ArcanistConfigurationDrivenUnitTestEngine)

This has been live for about a month without any followup concerns.