This message was deleted.
# report-bugs
s
This message was deleted.
f
Hey Ed! I can help look into this for you - do you mind sending me your org/repo name? (DM is ok)
e
Hey we’re still seeing this issue, @Pranathi Peri any update?
p
Hey there! Sorry about the delay here, I'll ask our MQ engineer to take a look!
He's taking a look now! Will keep ya updated 🙂
d
Hi Ed, I'm investigating. It looks like you are hitting an issue we have been trying to track down. Do you know if you repository has the setting "Require deployments to succeed before merging" turned on, or is using Github's "Rule sets"?
e
I believe I gave the Graphite App the required permissions when I set this up (I followed the instructions and it was working briefly). I will double check this setting.
So we’re not using any rulesets
And we do not have that “Require deployments to succeed before merging” turned on
Thanks for looking into this!
d
If you look at the PR on GitHub, does it provide any messages about blocking it from merging?
Do you know if you gave the
graphite-app
permission to bypass required pull requests? (see docs here)
e
Yeah I did give those permissions
I’ll get back to you on the first point
d
To provide some more light on what is going on...As part of the merge process, we will query github to get the "Merge State Status" of the PR, which is whether github thinks the state of the PR is (can it be merged, is it blocked by something, etc). In this case, that status is BLOCKED. Most of the time, BLOCKED indicates that there is CI that failed or is still running. Unfortunately, the github API doesn't tell you why it is blocked, just that it is. So we have been trying to track down what is causing github to think the PR is blocked.
e
OK, this is what we see on an example PR that failed to merge
All CI checks passed apart from one that was skipped
d
If you look at the PR in github, are there any message that would block the PR from merging?
e
nope
trying again now
Looks like Graphite rebased it as part of the merge process so CI checks are running again
I’ll let you know when it’s finished
d
👍
i see that merge failure in our logs. Everything looks successful to use. But github seems to think the PR should be blocked from merging.
e
OK all CI has passed and it’s stayed in this state in the queue for a few minutes, not sure why, I don’t think there is anything else in the queue
I need to leave for the day soon, so can we pick this back up next week? Is there anything else I can tell you to help debug?
Ah we just got the same message again
d
I'll dig in some more. I have an idea for a workaround I'll try to get into today. Then we can sync back up next week to see if that helps.
e
Hey @David Bradford did you find anything last week?
We currently have the merge queue turned off and we’d really like to use it!
d
I haven't been able to figure out the root cause yet, but I did deploy some code to detect this situation and try to handle it a little better in the MQ. At the very worst, it should provide me some better information to debug what is going on. So, if you get a chance to try to hit the issue again via the merge queue, so that I can try out the workaround code, I'd appreciate it.
l
We are still seeing this issue, is there anything which is being or has been done?
j
checking with the team, sorry for the delay!
z
Hey - sorry for the issue, can you DM me the PR repo and number? Thanks! I am not seeing anything on our side from the past week
l
I don't have that information available anymore sorry
e
Hi Ziyao, we had the merge queue disabled since we last discussed this until now. We figured we’d turn it back on and see if it worked again but unfortunately it didn’t 😞 The repo is project-nous/monorepo and the PR that recently failed to merge was 6386. Let me know if you need any other info.
🙏 1
z
Thanks, I’ll take a look later today. Sorry for the issues you ran into and I’ll keep you posted!
e
Great thanks 🙌🏻 Look forward to hearing from you.
Hey if it helps, I think the merge queue just worked for us with PR #6427 on the same repo. I followed the second half of the instructions on this page to “Enforce the Graphite merge queue”. I previously thought they were optional but maybe they are required?
💛 1
@Carissa Jansen this is the thread I referenced in my email
c
@Brendan Ngo is working on these bugs right now!
e
Great stuff, thanks 🙌🏻 One other thing we noticed today was that pull requests marked as hot-fixes were failing. Other PRs appear to be merging fine. Is that a problem you’ve seen before?
b
@Ed Smith What PR failed the hot-fix? I can take a look
e
#6438, #6444 and #6445 are recent examples
Some comments from the Graphite app say that they weren’t satisfying all the requirements
I think they actually were but can’t be certain as I’m not the author
b
It looks like these prs failed because they were missing approvals. Looking at whether this is expected behavior or not given we may be able to bypass branch protection rules
turns out we do not actually bypass the branch rules so these failed because they didn't have any approvers. hotfixes will just skip the queue
e
Ok I'm not sure I fully understand... Are we able to put prs in the merge queue without approvals? (I guess it might depend on our settings)
b
That is what's currently happening. But I agree with you this is unintuitive, let me investigate why we allowed this in the first place!
e
Great thanks! Yeah I'd expect whatever our settings are - say we require 2 approvals for merging (certain users may be able to override that) - then we'd need 2 approvals on a PR before it enters the merge queue (and certain users may be able to override that and put the pr in the merge queue without the required approvals). Marking as hot-fix would make it enter the merge queue at the front, but not allow it to enter without the required approvals. I'll catch up with the authors of the prs to see if I can get more info on what actually happened.