oops, i dont think i meant to submit to this repo

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

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.

Thanks, I'll look into this further. I didn't install it myself, I'll ask sysadmin permissions to get through the setup personally.

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.

I suspect this might be because the value for "Continue" is an empty string here: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php$27 ; At least, changing that value to be non-empty seems to solve this.

Actually, I can reproduce this at HEAD using a HTTP request step.

None of your versions exist here, meaning you have some local changes which might cause this.; Can you reporoduce this on Phacility?

Something else on your server is likely altering URLs. What OS is this? Is this a shared host? Do you have software like apparmor running? All things to look into.

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.

Yup, purging caches didn't help.

Unfortunately, we can't move forward, then.

I'm sorry, other than:

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.

I created a test-event now, it starts in an hour, and I will take a look if this occurs again.

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.

I understand bot users don't get email but I totally mis-typed one and I realized it "too late" and would love to be able to change it even if it doesn't really matter

Heh, just ran into this today

No problem, thanks for the report!

Awesome, thanks @epriestley!

I've marked D16909 as fixing this, but it just removes mysql.implementation, and uses the rule "mysqli if available, mysql otherwise".

I think this should be fixed now. Note that we still have T11165 floating around which may make it look like this is still an issue, by sending you to the wrong place when you hit "Save". That bug is dumb but fairly harmless so I haven't chased it down yet.

Oh, hrrrm, this is actually more involved since it's not just the .git clone URI that's in trouble. So I can't just ban . without fixing existing short names.

Okay, let me ban them for now and if it causes too much of an issue we can try just banning .git at the end.