Better error on absent next commit #1120
Conversation
| @@ -32,9 +32,13 @@ pub async fn handle_triage( | |||
| let start_artifact = ctxt | |||
| .artifact_id_for_bound(start.clone(), true) | |||
| .ok_or(format!("could not find start commit for bound {:?}", start))?; | |||
| // This gives a better error, but is still not great -- the common case here | |||
| // is that we've had a 422 error and as such had a fork. It's possible we | |||
There was a problem hiding this comment.
Can you explain this bit "422 error and as such had a fork" more?
There was a problem hiding this comment.
When bors fails to push with a 422 error (e.g., rust-lang/rust#91279 (comment)), which really shouldn't happen but isn't fixed yet -- see rust-lang/homu#75 for the issue tracking that bug -- we end up in a state where triagebot + rustc-perf effectively believe a commit has landed on master, but that commit hasn't actually landed. This is because triagebot looks for comments like this one rust-lang/rust#91279 (comment) when discovering new rustc master commits, not actually a push to the master branch on rust-lang/rust. (Plausible that this could get fixed alongside rust-lang/triagebot#1483).
The net effect is that we end up in a situation where this not-actually-on-master commit is believed to be, which means that when the next commit does land to rust-lang/rust master, we have a fork in the otherwise linear history of bors merges from triagebot's perspective, which means that next_commit stops working correctly on the rustc-perf side (there's two next commits, probably we choose a semi-random one?).
No description provided.