See Consulting if you'd like me to help you personally. Thanks!

• To click the "Land Revision" link, you must be able to push to the repository.
• The push is performed by the user that Drydock is operating as on the automation host.
• The reproduction steps and video above are consistent with this.

It's safe to do that (set utcInstanceEpoch = utcInitialEpoch for all events with a parentPHID where utcInstanceEpoch is currently NULL), with one minor caveat.

Why are users logging into sensitive accounts on shared computers? This action seems inherently unsafe to me.

Update past D16623 (Sep 28). See also T11705.

The upstream still doesn't have a reproduction case; we won't act until we have one. See Providing Reproduction Steps.

That change doesn't specifically do anything about mail tasks, but assuming they were coming out of repository imports it should probably clear them up too. I'd expect queue behavior to generally be more reasonable around repository imports once you pick up those changes.

Did you experience these issues after D16585? My expectation is that it should be almost impossible for PhabricatorRepositoryCommitHeraldWorker tasks to stall the queue for other priority-2000 tasks after that change.

@20after4, just a heads up about this per discussion in T7944. Here's what we expose today:

Well, just Conduit for editing -- querying is already in D16592.

I think making authorizations transactional isn't too much work. They already have PHIDs, and aren't edited in very many places.

I'm comfortable bringing this stuff upstream today:

(That doesn't solve the "engineers don't know how to initialize a new Git repository with git commands" problem, but I think that one's a bit more involved.)

I'm assuming the "empty" issue is that you have a rule like this?

If the major immediate issue is Herald disallowing branch creation with git push, we could add a Herald condition like "Repository is empty".

Here's what I'm planning to do for imports:

Hrrm -- what is max_allowed_packet set to in MySQL?

T11747 wants a more advanced version of this (reviewing diffs between rendered documents), although the specific document type it wants (IPython notebooks) is likely very complex to render.

I'm going to merge this into T5698. That isn't quite the same task, but would be the first step toward this.

I believe this should now be fixed in HEAD of master. It should promote to stable within 24 hours.

T11744 has a vaguely-related special case where "split + count" was unreasonably slow for very large inputs.

D16683 makes us bail early if the combined length of the old and new lines is larger than 1280 bytes, which is a crude test for approximately two reasonable-length lines of emoji source code.

It looks like this is largely just PHP being PHP. To handle UTF8 combining characters correctly, we're producing a list of strings like this internally as the atoms of comparison:

This should now be fixed in HEAD of master.

I'll look at this tomorrow but can probably figure it out from this. Initial guess is that we're doing this (which is O(big constant * string length)):

The root issue was that we would compute a ProseEditDistanceMatrix (roughly, a Levenshtein distance matrix) for large inputs, but this is O(N*M) in the size of the inputs and both of these inputs had ~2,200 "atoms" at the top prose diff level, so the matrix had ~5M elements.

Oh, one diagnostic tool that I didn't mention is that you can send SIGHUP to a running bin/* command to get a stacktrace of what it's doing dumped to /tmp/phabricator_backtrace_<pid> (usually). This one looks like it is a smoking gun:

Awesome, thanks! I'll dig into it and update you once I get somewhere.

Yeah, just take a shot at making a paste here (secure.phabricator.com) with the same degenerate behavior. If you can get us crashing I suspect I can get a fix in about 5 minutes through the power of adding var_dump() all over the place on the production server. If not I have a few ideas but there's a lot of code that could be causing the problem and that trace isn't an obvious smoking gun to me.

One other quick diagnostic is: when the worker is stuck, is there a pygmentize subprocess running?

Can you attempt to create a paste on this install which reproduces the issue? I have a few ideas about what's up, but that's almost certainly the fastest path to a fix if it works.

I don't think we should change this.

We'll accept this as a bug report if you describe the conditions which lead to a newline after "Summary:". The expected behavior is that there is no newline.

Oh, sorry, apparently @chad got this right then and I misunderstood.

Ah. From the workaround ("View Unified", then "View Side-by-Side") I'm guessing the menu maybe isn't refreshing properly somehow, but I'm not sure how to reproduce it given the provided steps.

I can't immediately reproduce this -- were you able to, @chad?

I merged T11740 and T11739 here since they're approximately the same problem from our perspective ("make messages adhere to project rules, where the project rules are immutable").

We use a heuristic to guess which function, class, etc., the context is in. Git uses some similar heuristic.

The code is a little better factored now and it's possible that the patch to DifferentialInlineCommentMailView is a pretty small one (and it may work in both text and HTML modes, as a possible benefit, although I suspect your install's use of HTML mail is much lower than most).

@klimek Your install is the only install we're aware of that is interested in a rendering mode like that (feedback about the old rendering was generally negative; feedback about the new rendering has been generally positive). Unless we become aware of much wider interest in such a rendering mode, I don't plan to reintroduce it upstream.

@HarryOtto, your message is off topic in this thread and is so tenuously related to anything here that it looks like it might be SEO linkbuilding spam, so I've removed it.

Design atrocity incoming for T10747.

I think there is an extremely rare policy error somewhere in the policy code that we've occasionally seen in the form of sporadic unit test failures. I haven't been able to reproduce them in the same environment and they're false negatives (e.g., prevent access when it would be OK to allow access) so I haven't spent a ton of effort hunting them down, but it's possible that they have the same cause.

Rough overall state of the world is that "all the hard stuff" is mostly "done" but it's probably fairly buggy, so I'm going to push on exports and some UI stuff for a bit and try to catch all those bugs while I do. Also imports are probably hard but I'm going to imagine that they aren't for now.

Yeah, agreed.

I think I'm going to move the recurrence controls to a separate screen, so you'll make a recurring event in two parts: