@rabahmeradi So it was, shortly afer reporting! Thanks.

In T11801#198622, @adam93 wrote:

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

As @epriestley said in the general chat "We're missing an (int) cast in PhutilRecurrenceRule::newFromRRULE() on INTERVAL and probably COUNT".

Mentioned in chat but just to keep it logged. Importing an ics file with the following RRULE (RRULE:FREQ=WEEKLY;BYDAY=TH;INTERVAL=2) works as expected opening in Microsoft Outlook, but gives the following error in Phabricator upon import "RRULE INTERVAL "2" is invalid: interval must be an integer."

This should be fixed in HEAD of master. Thanks for the report!

...and here are foreseeable issues with this mess occurring in the wild:

Broadly, I want to avoid implementing things that don't have good technical justifications.

I've done some more digging as well and it appears that this issue arose in the Go library already: https://github.com/golang/oauth2/issues/111

Is "GitHub-specific OAuth" just normal OAuth with client_id / client_secret as parameters instead of in an "Authorization" header? The GitHub OAuth documentation seems to suggest passing these as parameters, too.

It seems like section 2.3.1 is poorly worded. They talk about a "client password" but the example request only includes client_secret as a POST variable. In the case of the Golang OAuth2 module (which Concourse uses), it sets the basic auth username to the client ID and the password to the client secret (https://github.com/golang/oauth2/blob/master/internal/token.go#L164).

I think the textarea predates using JS magic to make "copy" work. I think we could probably remove the "disable highlighting" mode now; I can't really imagine any legitimate reason to intentionally disable it in modern code, except maybe not realizing that "copy" will work correctly via magic.

I don't think we have a "client password" in this case -- I believe that refers to a mode that no one uses for anything (well, maybe a mode that Concourse uses, I guess), where the flow is actually handling normal user passwords?

Protocol for URI "svn+ssh://..." MUST be "svn+ssh".

what

Calendar is a prototype application, and we don't accept bug reports against prototypes. See User Guide: Prototype Applications and Contributing Bug Reports.

I'm going to merge this into T10510, which discusses improving Harbormaster error behavior.

Another instance was reproducing this more frequently/reliably and reports that they're no longer seeing issues, and I haven't been able to reproduce it myself since the configuration changes. Presuming we're in the clear now, but let us know if you see further issues.

I think this is actually a bug between several of the 300 different pieces of scroll magic we have on the page.

I don't believe this is possible to fix without significant performance penalties for everyone else, given content is ajaxed in.

D16744 should also improve SSH performance slightly, with a larger impact on larger instances.

This may have been the "MaxStartups" directive in sshd; if so, a partial fix is currently deployed (raising the limit on application load balancers) and a more comprehensive fix will go out tomorrow morning (also raising the limit on repository shards).

Awesome, thanks for following up. Let us know if you run into anything else!

We deployed D16714 and reran one of the failing tasks -- it completed cleanly as expected. Thanks!

I'm going to merge this into T11357. We can provide a "Delete File Data" transaction type when we implement a third-generation file.edit API.

Is this a dup of (fixed) T10746?

In T11669#197945, @chad wrote:

It's always felt like 10% unpredictable to me, but I haven't tried it in a while.

It should show a pretty clear preview of what it's going to do before you drop, so I'm not sure how it could be unpredictable? I wasn't able to identify any weird/surprising behavior when I tried to reproduce this.

It's always felt like 10% unpredictable to me, but I haven't tried it in a while.

I wasn't actually able to reproduce this -- were you, @chad?

This is working as intended, and not a bug. Administrators can not bypass policies. See the User Guide: Account Roles documentation:

[ Ok ] [ Try Again ]

I'm pretty sure you're filing this ticket in the wrong place. We don't have any lyrics.

The blue group icon does hide the box. It didnt occur to me to try that, as it is not inside the box frame. I did look at the + beside participants, but guessed correctly that was only add.

After D16714, the problem tasks should complete cleanly.

D16714 should fix this by adding an implicit byte limit.

Sorry, "tomorrow" definitely didn't happen. Looking at this now.

If you have an exact Android version/browser I should test, let me know. We can also just make this smarter if you left it open on desktop (it should be off by default).

and I cant dismiss the participant list box.

It also occurs in landscape for my mobile. LG D335

And "request desktop site" does not work.

Still failing as of today (rarely though):

Building in workspace /Users/admin/Jenkins/Home/workspace/Hyper-tvOS-AdHoc
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git # timeout=10
Fetching upstream changes from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
 > git --version # timeout=10
using GIT_SSH to set credentials Phabricator
 > git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git
	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:763)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1012)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
	at hudson.scm.SCM.checkout(SCM.java:485)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1276)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1738)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh://hyper@vault.phacility.com/diffusion/HYPER/hyper.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: ssh_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

reported some bug under the line 32

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.

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.

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.