Couple of other things:

Likewise if this only might cause confusion, but has not actually caused confusion yet, it's a hypothetical problem (see Hypotheticals). We don't accept requests to address hypothetical problems because they often never actually occur.

This request doesn't describe a root problem (see Describing Root Problems), but we can only accept feature requests which completely describe root problems. See Contributing Feature Requests for more.

That setup is not supported, and we already raise a setup warning making it clear that major features will not work until the base URI is configured.

Why did you choose to ignore the warning, considering that it says "major features will not work properly" until you configure it?

When phabriator.base-uri is not configured, you should receive this setup warning:

@20after4, just a heads up:

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Yeah, looks like that reproduced it. Here are the caches:

After D16933, the behavior of arc browse <branch> on the experimental branch is:

Sorry, can't make it this time! I'll catch you guys next time for sure.

Sure, not a problem.

Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:

Okay, I believe we already produce a format which is compatible with that definition:

Maybe it would be simplest if you just give me an example of exactly what you want us to emit?

That sounds fine to me. Do you have any preference on what format you'd like the proto-english + variable type annotations in? Maybe something like this, since it sounds like you're doing some level of custom stuff on your side anyway?

Thanks for the report! I think D16924 should fix this, and one other issue that came up too. Both these are related to supporting multiple partitioned masters in connection with T11044.

If this reproduces at HEAD, it's a bug. Please file a new bug report with complete reproduction steps and version information.

I'm sure if I keep digging we'll be out of this hole in no time.

I'm not sure if D16857 is even close to the right level of generality or correct approach and the answer has yet to come to me in a dream, so I'm going to push forward on top of it and see how far I get. If too much stuff stacks up I'll maybe shove this stuff into an experimental branch for now until I decide whether I'm throwing it all away or not.

What do you need on differential.querydiff? We could just give you a modern differential.diff.search with a revisionPHIDs constraint.

sorry please do not fire me

The long-term fix is putting this stuff on EditEngine (some discussion in T11887) but this should be fixable in the short term.

Generally, our behavior here is approximately the same as Calendar.app and Google Calendar. T11804 documents how various edge cases behave in those applications. I believe our behavior is no more spooky in any case I'm aware of.

Unfortunately, we can't move forward, then.

Maybe this is a misinterpretation of "All Future Events"? That means "All events which start after this event starts", not "all events which have not yet occurred, considering the current time".

I'm still having trouble figuring out which past events were edited. Downstream has this query:

Oh, sorry, E66 would have been disconnected from past events by the edit. Let me look through the downstream task.

Assuming that's just a miscommunication, I can't immediately reproduce this locally:

E66 is the first event in the series, so I would expect editing E66 "All Future Events" to edit every event in the series: there are no past instances. Am I misunderstanding? What's an example of a past instance?

I'm not sure, then. You have the B rule, and your Apache is recent enough to support the B flag.

This seems to be working now. I'm going to let it sit in production for a while and see if any issues crop up before considering it resolved, but it seems like everything is working smoothly.

I configured 003 to replicate to 004:

Okay, we're headed back into readonly mode shortly to set up replication. I'm going to verify D16916 along the way so there may be some "partitions disagree about life" errors.

Here's what I've done so far:

I'm partitioning secure.phabricator.com now. Things will drop into read-only mode for a bit.

Okay, what version of Apache are you running? (httpd -v or similar may tell you.)

• T11908 is a followup for executing queries for multiple applications on a single connection. I believe the pathway for that is straightforward and fairly short, but that no install would really reap substantial benefits from it today, so I don't expect to pursue it for some time.
• I believe everything else is now complete, so I'll put this in production as soon as everything here lands and we can see what catches on fire.