The re-launched hosts seem OK, I'm waiting for DNS to update and then redeploying them.

The hosts launched into an "Auto-Assign Public IPv4" subnet but didn't get IPv4 addresses. Restarting them didn't help, and there's no apparent way to assign public addresses after the fact. I'm going to throw them away and try again.

I'm going to put more hosts into production immediately before pursuing other issues.

• Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

• The tier as a whole is 88% full.

So here's a tentative plan for subtyping:

Custom Forms are the general tool we want to use here, but they currently have some limitations for this use case. As a starting point, here's what they can do today, some of the strengths, and some of the weaknesses.

Maybe the "Install Arcanist" header on Quick Start could be like:

That is, this passage:

There's a short version and a long version. Each version links to the other version, saying "here's a different version of these instructions, if you'd prefer that one". How could we make this more clear?

This is a followup to a private discussion elsewhere, I'll flesh it out a bit when I have a chance.

Hibernating daemons currently show as "Waiting" in the Daemon console, but I'm not going to worry about that for now.

Ah, okay. This is the relevant part:

good luck w/ teeth 😁

Starting with repository update:

Broadly, there is nothing Phabricator could have done differently to anticipate or prevent this issue.

We could also provide some kind of bin/auth burn-everything-to-the-ground to automate these steps, but I worry that it would almost never be tested (I think it's very difficult to test comprehensively in an automated way) or run, and there's a good chance it might be forgotten about when authentication changes occur.

Ah, you're right. It looks like request data may also have leaked. I'll edit my earlier posts to reflect that. Briefly, the change is: passwords and VCS passwords are potentially at risk.

To cycle passwords, you can do this:

Although this problem is severe, the absolute size of the leak appears to be small (my task title is hyperbolic). From the Cloudflare disclosure:

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

I didn't "ref" it here, but D17401 sort of technically did this. I'd like to clean it up a bit more before calling this resolved, though -- particularly, this is basically a secret that only I know about.

Also, above, I used the term "deuteranomaly" when I meant "deuteranopia". I mistakenly believed they were describing the same type of colorblindness, but they are two different types.

Possibly this should really be three dimensions (Size, Contrast, Color Correction).

See T12060#213081 some end notes and followups.

See some additional discussion in T12172. Briefly:

@chad did another pass on user hovercards and they should be even more clear now (this screenshot doesn't demonstrate it clearly, but we also greyscale the profile photo);

Why do you have multiple authentication providers?

Yeah, I'm basically just keeping this open as a dumping ground for the moment and purely selfishly because my segfaults aren't resolved yet -- brew didn't have PHP 7.1.2 last I checked, although it seems like it now does. I've upgraded and I'll see if that improves things.

We need reproduction instructions which allow us to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

This has been "resolved" by switching to bartering various sundry goods and foodstuffs instead of billing via credit card.

No time like the present.

It is expected that taskmasters will exit and restart after an unexpected failure, but this should not trigger setup warnings. I'll see if I can reproduce this.

This might be the same as T12302, but I'll see what's going on.

Persistent chat was originally a separate column (so it didn't overlap with anything on the page) but was brought into the main page recently.

Yeah I'll take it, pretty sure it's my fault.

I think this is probbbbbbbably an actual bug unless I'm totally out of it -- possibly my fault from D17372.

No.

I believe this is effectively resolved now -- we're running all the daemons on multiple hosts on secure. There's remaining followup work (T6768, T6615, T10753, T10754) but I think the core is in reasonable shape.

T11708 has almost nothing to do with this, but the fix for this will rewrite the code that's running into issues and probably moot them.

I'm just going to merge this into T12115, which isn't really related, but will rewrite this code and probably "fix" this, since a reproduction case seems elusive.

This could probably be built with RRULEs now, but we don't currently have use cases / plans around a general-purpose cron-like tool.

Use cases seem to be fairly well covered now.

This is 2+ years old and autoscaling probably covers it now. T5401 is probably a more tangible attack on this.

This got a little more work when clustering was written but it's essentially a log of two-year-old ghost sightings at this point and not actionable.

I guess this one can live for now since that's reproducible/actionable.

Probably a dupe of T11708? I'm just going to kill this one since it's old as dirt.

I believe this was likely resolved by D16460. This (binary transport over Conduit) is still a problem in general, and T5955 is the general remedy, but diffusion.rawdiffquery specifically now returns data via Files.

I think it is likely that this was resolved by D17123. If it wasn't, we don't have a reproduction case anyway so we can't move forward. I'm going to call this one dead until more information turns up.

We were never able to reproduce this convincingly and as far as we know the reporting install no longer uses Phabricator, so I'm going to close this out.