Open Mariatta opened 4 years ago
One thing that could be taking up time and causing timeout is when it tries to lookup the original master
PR, and to remove the needs backport to X.Y
label from that PR. Perhaps we need to look into optimizing that somehow.
There were some funny things going on in that backport -- the original commit failed to mention the bpo issue (I missed this when merging it) and the backports created by Miss Islington also missed that. I added it back to the PR subject and body but maybe the damage was done. I also tried to close+open one of the backports (I think 3.9) but somehow one of the bots considered the closing permanent, so I closed it and created a new backport with cherry-picker -- but of course it also failed to have the bpo issue in the subject.
(And thanks for unblocking the commit.)
Hey, If this issue is beginner friendly. I can pick this up.
@Amyth07 my guess is it's not beginner-friendly as this seems to be a finicky issue.
@Mariatta Is there anyway to get a log or payload from these delivery errors? I have been making some PRs to bedevere
so I might be able to have a look, but it's difficult to debug a 2 year old issue without the old context becoming removed 😅
@DanielNoord unfortunately all we ever have is the delivery details from Settings in GitHub itself, and even then we have to notice and go digging them out in the list of every payload delivered.
@DanielNoord unfortunately all we ever have is the delivery details from Settings in GitHub itself, and even then we have to notice and go digging them out in the list of every payload delivered.
That's too bad.
One thing that could be taking up time and causing timeout is when it tries to lookup the original
master
PR, and to remove theneeds backport to X.Y
label from that PR. Perhaps we need to look into optimizing that somehow.
I'm not sure what this is referring to, see: https://github.com/python/bedevere/blob/83a2d2273d3825297e2a09ea4024b84ca210439d/bedevere/backport.py#L89-L116
As far as I can see this handler is only doing lookups in payload dictionaries and some regex matching.
create_status
and post_status
also shouldn't really be an issue here I think.
I checked the history of the file but that also doesn't give any hints.
Without any further details I think it might be hard to debug this. Perhaps others that are subscribed to this issue have more details? Otherwise I fear this might go stale due to a lack of details.
Here is another failed delivery. I tried to re-deliver and got another 500 error:
This is the only failure of the last 48h. Given that this issue is fairly old, it might be that the original failure was caused by something else, and the one I found is unrelated.
@ezio-melotti Do you have the url to which you tried to deliver? Based on the tests I have one potential idea:
The statuses url requires appending the {/sha}
but in the tests we don't actually test this and in the gh.post()
call we also don't supply the sha of the commit to which the status should be applied. Could that be the issue here?
The delivery I pasted above is the one visible from the GitHub webhook page of the cpython
repo, so it's the payload sent by GitHub to https://bedevere.herokuapp.com/
. I don't have access to the logs of the requests sent back from bedevere to GitHub (if they exist at all).
While looking into https://github.com/python/cpython/pull/21830, I noticed several failed webhook deliveries.
I attempted to re-deliver the same webhook payloads, but it seems that the webhook event consistently timed out for the payload below. I think we need to further investigate.
I found that if I removed the
[3.9]
from the title, then the status got posted immediately. (no timeout). And if I removed the(GH-21773)
, it also succeeds without timeout.Click to see delivery details
``` { "action": "edited", "number": 21830, "pull_request": { "url": "https://api.github.com/repos/python/cpython/pulls/21830", "id": 466150827, "node_id": "MDExOlB1bGxSZXF1ZXN0NDY2MTUwODI3", "html_url": "https://github.com/python/cpython/pull/21830", "diff_url": "https://github.com/python/cpython/pull/21830.diff", "patch_url": "https://github.com/python/cpython/pull/21830.patch", "issue_url": "https://api.github.com/repos/python/cpython/issues/21830", "number": 21830, "state": "open", "locked": false, "title": "[3.9] bpo-41504: Add links to asttokens, leoAst, LibCST and parso to ast docs (GH-21773)", "user": { "login": "gvanrossum", "id": 2894642, "node_id": "MDQ6VXNlcjI4OTQ2NDI=", "avatar_url": "https://avatars3.githubusercontent.com/u/2894642?v=4", "gravatar_id": "", "url": "https://api.github.com/users/gvanrossum", "html_url": "https://github.com/gvanrossum", "followers_url": "https://api.github.com/users/gvanrossum/followers", "following_url": "https://api.github.com/users/gvanrossum/following{/other_user}", "gists_url": "https://api.github.com/users/gvanrossum/gists{/gist_id}", "starred_url": "https://api.github.com/users/gvanrossum/starred{/owner}{/repo}", "subscriptions_url": "https://api.github.com/users/gvanrossum/subscriptions", "organizations_url": "https://api.github.com/users/gvanrossum/orgs", "repos_url": "https://api.github.com/users/gvanrossum/repos", "events_url": "https://api.github.com/users/gvanrossum/events{/privacy}", "received_events_url": "https://api.github.com/users/gvanrossum/received_events", "type": "User", "site_admin": false }, "body": "(cherry picked from commit e3c971ccfa58afcb2656b71b95e10b9703f2ad32)\r\n\r\nCo-authored-by: Edward K. Ream