probably still a bug somewhere else tho, but i solved my problemo

yay I found the double render

This page renders transactions twice, by example, at line 39. Nothing else renders twice. I poked around AphrontAjaxResponse and nothing looked hokey, but I can't really figure this out. The double transactions appear to come from multiple render calls somewhere in AphrontAjaxResponse?

reported some bug under the line 32

As a followup, ran this script on a subset of instances to collect data about mail delivered on a per-action basis versus a per-user basis:

Per above, here are the specific queries I executed while collecting statistics about the "Self Actions" preference:

I am running a query to collect this data:

Circa September 13, 2016 we ran a query which collected this data from instances:

Such task

Ah, thanks! Yeah, looks pretty conclusive.

Yep! It looks like that's the issue:

I'll give that a try. I think the associated diffs have enormous lines, so it seems likely that's what's going on.

This is expected.

I'm vaguely suspicious that the mail is just too big (1MB of text plus tons and tons of HTML for syntax highlighting it?), and that the error is really arising from max_allowed_packet being violated, particularly given that the INSERT took 233ms to execute.

(Following up for Greg, as I'm now the oncall.)

mysql> select @@max_allowed_packet;
+----------------------+
| @@max_allowed_packet |
+----------------------+
|             67108864 |
+----------------------+
1 row in set (0.00 sec)

metamta.differential.inline-patches is 500.
metamta.email-body-limit is still the default of 524288.

I'm so excited about this ticket :)

Somehow this didn't autoclose.

This feature request does not describe a root problem. See Describing Root Problems.

I agree that there is no sensible technical reason for the broken network policies that prompted my comment and understand your reasons for preferring to punt on a technical solution. Thanks for your thoughtful remarks.

(If the policy isn't fixable, you can personally bear the cost of this policy by tunneling the traffic over 80 or 443 locally.)

Have they asked network operations to allow outbound traffic on port 22? It seems like organizations which employ software developers should reasonably permit this traffic. Particularly, security-minded organizations should reasonably prefer asymmetric keypair authentication over HTTP password authentication in the general case.

Some GHC contributors have had some trouble with the fact that there is no choice in staging area URL. Unfortunately, some users appear to be behind corporate firewalls which block anything but http and https. We use SSH for our staging repository, which is of course problematic for these contributors. There are a few comments above from Nov 2015 which suggest that we aren't the only ones who have this issue.

Hmmm I'm not seeing those lines in that file anywhere. On the current head of master, I'm pretty sure the viewer is always set to PhabricatorUser::getOmnipotentUser() in TransactionPublishWorker. Although maybe that isn't making it all the way to the policy aware query in every case.

@jcox I just noticed this line from you:

@jcox, I dove into this a bit, but like you, I didn't come up with much. We have not used bin/remove destroy for any of our repos and there doesn't appear to be any meaningful relationship between the failing tasks that I have found yet. The script that @epriestley kindly provided was able to load any diff I threw at it. The script was helpful in determining the right queries to make to investigate further.

See Phacility Consulting if you're interested in hiring us to help troubleshoot local issues. Otherwise we need reproduction steps to be complete and reproducible in our own environments if there is a bug present. Unfortunately we're not staffed to provide one on one support like this for free. Offhand, sounds like something is wrong with how JavaScript is getting delivered. Apache config (page modspeed), proxies, anything that alters the packaging should be looked at.

unfortunately I do not know since when it stops working.

I also can't reproduce locally or on Phacility. No other installs are reporting issues. Given Phabricator was not updated and the bug appeared, I'd have to think it's a local issue to your install and not a bug in Phabricator.

Works here.

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

Yes, this is my mistake, sorryyy

Just checked this morning and many tasks have returned and started to fail again. I'm sure there's a way to reproduce this, but our setup is a bit complex and I'm not sure where to start. @epriestley Could you tell me how to determine what these tasks are even doing? Is there a way to see what action triggered them and why they will fail indefinitely?

• 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.

Thanks for the quick response!

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

This is a screenshot of the status page. This can usually be fixed by manually rescheduling an update by either clicking "Update now" or calling "./bin/repository update" in command line.

Specific attack scenario: Phabricator is used to host proprietary code. Someone logs into Phabricator on a shared computer and forgets to log out. That shared computer is now forever logged into his account, allowing anyone using it to access said proprietary code. If the cookie would expire or at least be session-only, the risk would be significantly lower.

Would it be safe for me to write a migration that sets utcInstanceEpoch equal to utcInitialEpoch on every row in the calendar_event table?

After running the migrations, some instances of recurring events end up with null for the utcInstanceEpoch column. I'm not sure how this happened, however, as some of the instances have a value that matches utcInitialEpoch and I'm not entirely sure what the purpose of utcInstanceEpoch would be. If it matches InitialEpoch then it seems kinda useless, as does null...

@epriestley: Sounds good to me, this seems quite sensible in every way.