There are some, uh, creative things you could do if the problem is limited in scope to a few specific conflicts, like write a Herald rule like this:

I think this is just the same as T5046. You can use SSH, or wait for a fix for T5046.

This report doesn't have enough information for us to reproduce the problem you're experiencing or help you resolve it.

I'm going to merge this into T8345, which discusses this and some other relationships. My general concern here is that I don't want to add a large number of very similar relationship types which differ from one another only slightly. That said, "Followup" is probably the most compelling new relationship type discussed there.

Just to clarify, you aren't actually using Phabricator yet, and are just identifying this as a potential concern -- is that right?

I created OpenStack, you should have permission to edit it. Feel free to change the name/icons/description/permissions/etc -- the restrictions on project creation are just because they're relatively long-lived objects and users poking around / testing things loved creating random test projects.

No, I fixed it manually.

Cool, glad to hear things are working again.

A third case is that, as far as I can tell:

Details inline, but I think the shortest path to getting what you want here is:

You can add such a field yourself:

Those service calls look fine (~4.5ms -- about the same as this install) and the 150ms discrepancy between the 654ms on the network tab vs 500ms of observed wall time isn't too far out of line (I see about half that discrepancy on this install, but services can't do true end-to-end timing and at least some of that time is spent saving Services data after the timer stops).

It looks like you have to configure an application key -- is that right? Did you just hard-code yours? That might be a possible technical hurdle, since other OTP auth doesn't require configuration so we don't have anywhere convenient to store it. Or I might just be misunderstanding how the verification works.

Oh, so we just need a query language to make this work? Do you think it would be better to build the query language first?

So sometimes selecting "A, B, C" as a query means "A AND (B OR C)", and sometimes it means "A AND B AND C", depending on whether B and C are from different projects?

When you search tasks, do you expect to have separate query UIs for "Marketing" tasks and "Development" tasks, or a single query UI (with support for querying by either field) for both?

Phabricator does not support per-project fields, and we have no plans to add them at this time.

Per T8744 and elsewhere, the "Synthetic Inlines" for lint and Differential coverage both still need to be switched to read from Harbormaster sources.

Thanks! This is now deployed.

niice

Aha! I think I figured it out.

SELECT * FROM phabricator_almanac.almanac_service;

Show me the row?

My theory here is that your services table is kinda messed up, but I'm having a hard time coming up with a clean way to fix this in the general case. I think I'm just going to soften the failure here for now, unless that query produces surprises.

From T8781, monitoring instance daemon queue lengths would be particularly helpful in identifying at least 1-2 issues we've hit.

Do you have stuff in almanac_service?

You can also probably do this to get a meaningful stack trace, near line 410 of PhabricatorCursorPagedPolicyAwareQuery.php:

Actually, I guess we can't check the environment that early to see if the setting is set. Let me just start by tailoring the error message, and maybe that'll give me enough to go on that I can figure it out.

Ah, okay. Let me fix that UI to respect developer mode so we can get a stack trace.

Oh, sorry, I just mean the web UI itself -- I'd expect it to look like this if you have developer-mode enabled:

Do you have a full stack trace? You might need to bin/config set phabricator.developer-mode 1 to get one, although presumably you're already in developer mode...

This looks like it was primarily caused by operator error. I stopped some services on the paired repo host in order to recover db001 in connection with T8764 yesterday. This worked, and let me revive the host immediately rather than needing to restart it, but I then failed to completely restart services later.

I think the immediate issue is now resolved, I'll look at this in more detail and post a followup a little later.

Looking into this now.

Seems resolved in the example. This is not 100% completely perfect yet (there's still some cruft kicking around) but I think it has no user-facing impact anymore.

Oh, @chad is correct, I get this mail on this install.

Thanks.

No. If there was, it would be posted here.

Thanks.

However this is, as you already mentioned, rather useless, because clicking the link will not allow to send an email

I can't reproduce this:

No worries, sorry these aren't working right now. We swapped hosts out and some of the domain rules changed a bit.

Oh, and remove the scripts from version control if their chosen destination is not Diffusion, I suppose.

Since this migration is ~18 months old and there's no easy way to correct it, I'm just going to no-op it. You'll need to update your repositories to set the correct credentials after upgrading.

We should fix this since it's confusing, but I don't want to put www.phabricator.com back in service as a host since this was the only thing it was used for.

I pushed a change to record instance out-of-service dates (D13561) and stop running backups for out-of-service instances after about 48 hours (D13563). I promoted these changes to rSAAS stable and deployed admin. I manually updated all "Suspended" and "Disabled" instances to have an out-of-service date of July 1, 2015.

(I think this is fixed?)