Noted by xdo: currently statuses are only held, stored, and validated at the PR level. The non-commit / non-webhook statuses added at 73b603d didn't change that part, but it means batches are allowed to be inconsistent, we get the results for PR N at head H, but we don't store / keep that it's when paired with PR O at head I, the runbot might be testing PR O at head J, or even not know about PR O at all and be testing against the head of the target branch!
For stagings, statuses are stored on the staging associated with individual heads, and since staging heads are immutable a given staging ID should signify a head-set (though that's not specified per-se in the endpoint, just assumed).
For batches every head can change at any moment, so the endpoint would probably have to take a set of PR heads (or a map of PR:head), alongside the PR / head for which it's sending a given status. In fact for batch calls the structure could be something like {(pr, head): {context: status}}, with an empty dict if there's no status to update for that PR. check with @Xavier-Do if that would be suitable or if some other protocol would be better (e.g. initial thinking was to just extend statuses_pr with a list/set of heads, but allowing status batching might be useful)
Noted by xdo: currently statuses are only held, stored, and validated at the PR level. The non-commit / non-webhook statuses added at 73b603d didn't change that part, but it means batches are allowed to be inconsistent, we get the results for PR N at head H, but we don't store / keep that it's when paired with PR O at head I, the runbot might be testing PR O at head J, or even not know about PR O at all and be testing against the head of the target branch!
For stagings, statuses are stored on the staging associated with individual heads, and since staging heads are immutable a given staging ID should signify a head-set (though that's not specified per-se in the endpoint, just assumed).
For batches every head can change at any moment, so the endpoint would probably have to take a set of PR heads (or a map of PR:head), alongside the PR / head for which it's sending a given status. In fact for batch calls the structure could be something like
{(pr, head): {context: status}}, with an empty dict if there's no status to update for that PR. check with @Xavier-Do if that would be suitable or if some other protocol would be better (e.g. initial thinking was to just extendstatuses_prwith a list/set of heads, but allowing status batching might be useful)