Why is <this PR> still in “Needs your review”? I a...
# report-bugs
t
Why is this PR still in “Needs your review”? I approved it, so two of the conditions should not be met.
p
(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using
gt feedback --with-debug-context <any message>
hey Tyler, other than a sync delay between the Inbox's state and the PR's current state the only thing that comes to mind there is if the filter condition for "Active reviewers do not include: tylerlaprade" is mismatching
t
Even if that’s the case (doesn’t seem to be affecting other PRs though), shouldn’t the Review Required filter have excluded it?
p
ah yes as well, I think that confirms it's due to the Inbox data for the PR being stale vs the actual in GitHub
t
Nope, something more bizarre:
I haven’t touched this branch or even checked it out, but somehow GitHub says I did all these actions
I manually merged the PR below this one (not by me, and not by the author of this PR either). That seems to have mistakenly associated all these actions with me and blocked the PR.
This is really bad because it means I can’t ship my teammates’ work when they’re all on vacation or in another timezone (which is currently the case)
p
when you say you "manually merged the PR below this one", did you do that from in Graphite or GitHub? The activity seen there looks to me to be automatic rebasing, which gets kicked off when a downstack PR is merged
t
Graphite
I would expect automatic rebasing to be associated with the author of the stacked PR
Assuming this bug also occurs with automatic merges, that would mean a team of two that stacks on top of each other would never be able to merge