This has seemed pretty stable for about a month. Future work is tracked in more specific tasks.

This fix appears to be holding.

I'm going to merge this into T9028. Specifically, D16133 rebuilds the summary table after any commit becomes unreachable, which should produce the correct commit count and other summary details.

D16134 just hard-codes phabricator/ tags as untracked, which should minimize collateral damage.

Yeah, the actual rule D16129 implements is this:

they are mine T.T

We could do posts too, but I only have 3 arts so far, so blogs seemed easier to start with.

I've deployed this and configured this server to use AES-256-CBC, although I haven't retroactively migrated existing data.

We can't reproduce this and haven't seen other reports of similar issues (including from other installs of greater size and complexity), so we have no way to move forward on this.

Bookkeeping; there's no longer an external driver for this.

Just bookkeeping; this doesn't have an active external priority driver.

Just bookkeeping, this doesn't currently have external priority.

This should be fixed at HEAD of master. Let us know if you're still seeing issues after updating.

T11044 makes this both more relevant and somewhat easier.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

To revive deleted commits when they are re-pushed, I think it is sufficient to ignore deleted commits when filling the discovery cache (PhabricatorRepositoryDiscoveryEngine->fillCommitCache()) and allow recordCommit() to detect existing commits and revive them.

Current state of the world after D16108 is:

Thanks for the report! This should be fixed once D16128 is reviewed, likely later today.

Thanks for testing, that's quite helpful.

Generally, I think resource autorelease (using @hach-que's rule) is probably the shortest pathway forward here. You'll still have a fairness problem, but you should get better utilization from the pool and be deadlock-proof on "A", "A" type acquisitions. This also tends to trigger less adjacent work than new resource types would.

Being completely fair also means we must execute without parallelism, because if we start position 2 without waiting for position 1 to finish it might win, and this could keep happening forever.

The expectation is that allocation should generally be fair ("first come, first serve") when no allocations fail.

You can determine both of these from the harbormaster step dependency tree.

I'm planning to do this:

See some prior discussion in T10081, which I'm going to merge here.

I think this also increases the chance that users accidentally disable or misconfigure (e.g., by misusing Match user) administrative sshd by requiring more extensive changes to its configuration. Users locking themselves out of the host is the worst outcome of a configuration attempt by a huge margin.

Can you provide:

@bizrad6 Thanks, I think D16118 should fix that once it lands. Sorry about these issues, the actual global stuff happened at the very end of the settings changes and I didn't test it as thoroughly as I should have.

My tentative plan is to define keys in local config with some sort of structure like:

Ah I see. So for the "create ticket" workflow, it only seems to happen when creating a ticket from a workboard. In this case, I do not see the button go disabled.

I was able to reproduce this on a Phacility test instance as well: https://test-ftzenxozitfe.phacility.com/phriction/edit/?slug=/

I am using Chrome on Ubuntu, but I don't think k the browser/OS has much to do with it. I'm guessing that you can't reproduce it because you have more internets than I do. If you can artificially throttle the connection speed then it might be easier to reproduce.

Cool, pretty sure I've got a repro then -- real fix coming up in a second.

Ah, I think I've got a repro. Does this "fix" it?

There's a very small possibility that D16110 fixed a race condition which was causing this, but that seems like quite a stretch.

GitHub does not appear to ever render absolute time. Instead, it renders relative times like "5 hours ago", etc.

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.