Looks like you've got the other half of this.

Oh, well the "upside down" part at least.

yeah this is 100% me

• I manually removed the restart from the logrotate script. I'll make that part of deployment when I make other deployment changes.
• I pruned a handful of obviously-not-in-service test/demo instances and restarted the daemons to terminate their associated daemon processes, which gave us some additional headroom.
• I manually configured 16GB of swap on the ephemeral drive. Depending on how that goes, I'll make that part of deployment. I'm not yet sure if we're better off or worse off with swap, but it's conceivable that swap may be a good fit for this workload.

I also issued a 24 hour service credit to all instances, as this was a significant unplanned service disruption.

Users might encounter this before we have a chance to run any setup checks. Probably worth adding a note to the backup/restore docs.

I think the chain of events was:

This is also an issue in Conpherence, see T7566.

See T5095 , approximately.

Do you not see this?

Click "Search" in the left menu from within Conpherence, at the top.

It looks like logrotate restarted Apache (by default, it does this weekly to rotate logs) and it failed to come back up (which is catastrophically bad).

We plan to address every open task in Maniphest, yes.

This is fixed by D12360.

Anyway, this is somewhere in the 4-8 hour range and I don't think it needs to block on T7805. If T7805 happens first, that might reduce the estimate here by unearthing some of the common technical debt.

Yeah, that could work. The v0 dropdowns don't feel too awful to me, just a bit clunky.

That is, I think you still need to make a distinct "relationship type" choice somewhere along this workflow or we'll just end up with an unusable mess of a dialog at the end, especially because objects will probably eventually be able to have multiple different relationships to the same object (I think revisions already can: they can both "revert" and "depend on" another revision, although this doesn't make a huge amount of logical sense).

I'm still blocking D8685 for no particular reason, that might be a good place to start. I think grouping the menu up probably makes more sense -- at least as a starting point -- than trying to build a unified object relationship dialog (which feels hard to get right, offhand).

Thinking about it, I imagine we'll never actually bill above an estimate (at least, without some kind of confirmation/approval first based on new information). We should possibly just make that explicit, although I'd like to keep things as simple as possible and there's already a remedy available: don't pay us.

I don't expect this to meaningfully impact performance unless we end up with a really fancy animation when cards fly around.

If we did T7805 first and got a generic ApplicationSearch endpoint out of it, I'd be open to writing this as an extension CustomField and then disavowing all knowledge of it. The results UI wouldn't be custom, but maybe that's fine. We might need to pay down some infrastructure debt to let installs put this immediately underneath the "Title" field, I think a couple of the fields are still hard-coded.

I think there are two major product questions:

Can we just change "Select" into two buttons "Blocks" and "Blocking" (or whatever language, those hurt my head)

This seems structurally correct but is a lot of work.

Looking at this again, it's actually less problematic to change than I originally believed.

Project watchers are affected in the same way; see T6183.

@chad, do you have any clever design ideas on this? The best thing I can come up with is sticking a dropdown in the dialog, but that feels really clunky and hard to use to me.

I think this is roughly in the 30-60 hour range, but it's blocked by T4100 which is a large, highly-connected infrastructure task, so we can't prioritize it until that's complete. We should have a better idea of exactly what's involved here after that's finished. I'm working on T4100 now, other priorities permitting.

I'm not totally opposed to pursuing this, but this is mostly a product question since I don't immediately see a great way to surface it in the UI. We can just dump it at the bottom of the "Create Task" screen under the preview, but I worry it will be hard to spot and use if you have to scroll all the way down the page. @chad, do you have thoughts on this in general?

Very roughly I'd guess this is somewhere in the 80-120 hour range. D9204 is a very bare-bones technical implementation which attempts to show that the feature is possible, but this needs a great deal of product and integration work on top of that.

I'd guess the simple version (just a "something on this workboard has changed" notification) is about 2 hours of work, and needs to happen first anyway.

• Using ApplicationSearch here is roughly 8 hours of work.
• We'd like to ship that first and see how it feels, but if we need to provide separate ordering/filtering for queries in this dialog vs queries in general that's probably 2-3 hours.

Ah, thanks! I'm just going to merge that here since I think this is more complete than that one, now.

It looks like we also have access to id here, which is probably (but not necessarily) the same value:

We'd like to make that dropdown show your custom queries instead of a hard-coded list of fairly arbitrary defaults. (I think there's some discussion of that somewhere, but I wasn't immediately able to dig it up, and I don't think we have a task filed yet.)

This is 1-2 hours of work.

• Fixing the most general problem here (T2549) is in the 20-40 hour range.
• Fixing just T6707 is about 1 hour.
• This could also possibly be avoided if Google has permanent primary account identifiers now (instead of email addresses), assuming that both Google accounts were really the same account and they weren't recognized as such because we use email addresses as a primary identifier. I vaguely recall this being an issue when I wrote the integration originally, but Google was evolving auth a lot around that time and there might be a more durable identifier we can use now. This is ~1 hour to check and 2-4 hours to implement if something suitable is available. This problem likely wouldn't be possible with most other OAuth providers, which do have durable identifiers (e.g., user IDs).
• We don't need to use the username as an input to any of the auth hashing, so we could remove the "changing usernames logs you out" interaction. This happens only because all the hashes invalidate, not because there's any fundamental security goal served by invalidating sessions. This is probably 3-6 hours of work.

This is probably 2-3 hours of work at the outside, but I'd have to spend 30 minutes poking around with a profiler to be sure. There's a small chance it's more involved, but I believe we're just doing something needlessly inefficient when computing diffs-of-diffs and that there's nothing fundamentally hard or involved here.

Formalized here:

Do they have "Send me an email" Herald actions? Herald is now stronger than notification preferences, after T7731.

I'm going to clean this up a little bit and publish it as policy and we can see where it goes. It's possible that there are essentially zero customers who are authorized to spend $150/hr without going through a contract/approval process, in which case I'll have wasted a couple of hours, but if we convert even one protracted contract negotiation over to this reduced overhead system it pays for itself immediately.

We're potentially open to adding limited-access accounts but haven't seen much demand yet (so we aren't sure what they should look like) and there isn't a really a bright line between "limited access" and "full access" that we can identify offhand.

We can prioritize this immediately, I'll follow up in a private thread.

Presuming this is resolved, but let us know if you still have questions.

The task title has a "title" attribute so that you can see the entire title if the title is very long and gets truncated because you resize your screen to be too narrow to show the entire title.

interface for commands is using images everywhere, instead of text

No rush on swapping the handle stuff over, I figure we'll do that a piece at a time as it makes sense, sort of like the processRequest() -> handleRequest(AphrontRequest $request) change.