DCO bot is stuck in "waiting for status reported"

[brianjmurrell]

We are getting PRs with DCO required stuck in waiting for status reported. I had one in that state to show which I reported on #69 but could not leave that PR in a state to be inspected as the patch had to land so that we can make progress.

But that is only one of many instances my users have reported this probot being stuck in waiting for status reported.

[brianjmurrell]

Any ideas on this? I can't really use this when it holds up PRs from landing due to the bot being stuck.

[hiimbex]

Hi @brianjmurrell, I glanced through the logs and nothing stood out. You're welcome to self-host the app and control the logs and attempt to troubleshoot that way. PRs welcome if you figure out the issue.

[ichekrygin]

I stumbled across this couple of times in last few days. With no apparent reason, DCO check will get stuck in DCO Expected — Waiting for status to be reported. The only way to work around this was to close and re-create new PR.

[ichekrygin]

Observation: this could be entirely coincidental, but I think I just managed to get it "unstuck" by creating a new branch + new pr, i.e. identical copy of my PR w/ stuck DCO. After that both PR's sow DCO check as "successful"

[hiimbex]

A force push or new commit or new PR will always re-trigger the check if necessary.

[ichekrygin]

Yes, the check was triggered every time, and yet every time it was getting stuck.

[skhoroshavin]

@hiimbex I also have this problem, and force pushing did help once, but today I tried force pushing 4 times (as well as trying to close/reopen PR) without success

[klarose]

This just happened to me here: envoyproxy/envoy#6804

Haven't tried "fixing" it yet by repushing.

[skhoroshavin]

I sometimes see weird timestamps on github events (including my previous comment in this issue, which right now states that I wrote it 3 hours from now, i.e. in the future - sic!), so it is possible that issues with DCO bot are just consequences of broken timing in github.

[hiimbex]

Could be connected to this: https://twitter.com/githubstatus/status/1126171459255185414. But again, a force push or new commit or new PR will always re-trigger the check.

Again, I'd be happy to review PRs if anyone figures out the root cause of this, but I really have no clue.

Twitter

GitHub Status on Twitter

“For a period of time today (~3 hours), some of our servers recorded incorrect time zone information during a routine update. We’ve remediated the issue and are currently working to correct any inaccurate timestamps. Apologies for any issues this may have caused.”

[klarose]

That seems likely. I don't understand this infrastructure (probot, github integration) at all, so maybe this is crazy, but is there anything that polls the dco on a date-based timer? E.g. alarm(now_as_date() + 2seconds). If now_as_date() is in the future, (due to the time zone blip), it'll never wake up in a reasonable amount of time. I have seen this class of bug quite often in systems code that uses the wall clock rather than a timestamp, but I'm not sure how likely it is in javascript.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?