Hey folks! I'm looking at adding an optimization t...
# how-do-in
Nickolas Solum
03/18/2026, 12:44 AMHey folks! I'm looking at adding an optimization that will require PRs that survive a bisect get automatically fast-tracked back into the merge queue (instead of added back normally, like it is currently). I'm looking at doing this after a webhook but don't see a way to trigger a fast-track/hotfix from the server side and mq-update-entry-to-hotfix seems to only accept cookie/session auth rather than a token.
Is there any way we can currently accomplish this? If not, it would be great to either have a setting to fast-track bisect survivors or trigger mq-update-entry-to-hotfix with a token.
✅ 1
p
Pylon
03/18/2026, 12:45 AM(If applicable) To help us more clearly understand what you're trying to do, please provide additional details about:
- Screenshots / debug logs / list of commands you've tried to run so far
- Your workflow
- Current state
Pylon
03/18/2026, 2:33 PMHey Nickolas, I dont believe we have a way to support this today but checked internally just in case. I thought perhaps adding the fast track label would work here but suspect there are a bunch of times it wouldnt do exactky what you need (ie you cant fastrack multiple PRs in a stack IIRC). Will circle back if any ideas come up internally and capture this request as a future enhancement
👍 1
n
Nickolas Solum
03/18/2026, 2:50 PMThank you
p
Pylon
03/18/2026, 2:52 PM2 things from the team here:
1) The PRs that are added back after failure handling should already jump above everything queued after it
2) If you see lots of batches going into failure handling, and this is significantly impact your merge times our recommendation here is to turn down their batch size
n
Nickolas Solum
03/18/2026, 2:58 PMGood to know! Thanks again!
Nickolas Solum
03/18/2026, 4:58 PMThe reason we wanted to "hotfix" here is for the batch size of 1. We're wanting to not run some of our CI (uploading some assets) in bisects to save CI time, as it's not needed there. The only concern is that in the rare case that there's an error in that step, an infinite loop could occur if where it hits the error, gets put into bisect, and then pass bisect because we skip that step. If we have a batch size of one for the item passing bisect, the problem would be fixed as it wouldn't be put into a bisect group.
Rather than hotfix, is there a way to set batch size for items passing bisect?
p
Pylon
03/19/2026, 1:58 PMthere is not a way to set batch size of bisect today