confirm noomhq is operational again

As a very mild silver lining, I'm pretty sure this was the actual root cause of the webserver hang, and it's relatively tractable. Here's what appears to have happened:

I think the issue is initially resolved now, is anyone with an affected instance still seeing an issue?

Pretty sure I've figured this out but resolving it will take some finesse.

Pretty sure I've figured this out but resolving it will take some finesse.

Looking up service metadata for some subset of instances is failing, I'm not sure why yet or how large that subset is.

our stuff is still down

Looking into that. There are some additional issues with queued daemon tasks on admin as well that I'm looking into, unsure if those are symptoms of the web issue or not yet.

I connected to the server around 5:55 AM PST and rebooted it after inspecting things, service was restored around 6:02 AM PST.

Events so far:

Thanks man, appreciate it.

I'd translate 'Set Sail for Adventure' => 'Segel setzen' and add 'German' => 'Deutsch' (and similar for the other languages).

Looks like using [[ Prioritization ]] doesn't trigger that it's a good link. But [[ prioritization | Prioritization ]] does.

This is my Aphlict configuration:

(It's quite possible that I am doing something wrong here)

very nice

seems ok to me.

test

test

I think that story strength thing is non-retroactive? This may not really be fixed if new stories aren't better.

There's some level of magical heuristic, so yell if you still see issues.

When we make progress, we update tasks. We don't have a secret hidden version of Phabricator full of progress updates that we're hiding from the world.

Two years later, any progress on this? I have the same intention as several of the comments, which is to simply embed code blocks in a numbered list of things to do.

I'd love it if I could just click on the "Blocked by" or "Blocks" label on a task and be taken to the Maniphest query for all the listed tasks.

I'm going to merge this into T6018, which I think describes the same bug.

I think it's OK for the UI to show different stuff from the actual query fields -- it's OK to query by "Invited" but see "Attending" in the list. It's just confusing right now because it says "Attending: ..." but includes not-RSVP'd users.

test

test

test

test

test

Test

A few possible directions:

(I don't like actually un-cancelling the instances because that makes cancel + reinstate not get you back to the original state, which is inconsistent with how those buttons work for other objects.)

Yeah, I think the dialog should clarify.

Or the button could just say "Cancel All" and "Reinstate All" maybe? I think it's probably clear enough as long as it has different wording than the instance version, and has the word "all" or "entire" or "whole" or "series" or something on there: the dialog can clarify exactly what it means.

I just think it might not look pretty on standard resolutions (like my Mac)

Maybe it's fine to just use "Reinstate All Recurrences", and then explain what that means in the dialog? I suspect we aren't going to find a succinct, clear wording for "Reinstate All Currently Un-Cancelled Recurrences".

Technically I suppose you could have cancelled an instance after using "Cancel All Recurrences", which might make the word "previously" misleading -- "prior to now" is correct but "prior to the time when you cancelled all recurrences" might be the interpretation. So maybe "Reinstate All Currently Un-Cancelled Instances" is perhaps even more clear?

Alternatively, we can make reinstating a series un-cancel all cancelled instances. That would make some sense to me.

"Cancel All Recurrences" works because it will keep already cancelled instances that way. When you reinstate the series, all the individually cancelled instances won't be un-cancelled, so "Reinstate All Instances" doesn't really cover it. It should be more like "Reinstate All Previously Un-cancelled Instances". How would we put that succinctly?

Just more JavaScript.