Billy Keyes

> There is _nothing_ reported when the job isn't run due to the path filter not being matched. Or at least nothing that I can find. Yeah, that sounds right....

@iainlane while looking at #807, I realized we may have a bug related to this: the handler for the `check_run` event, and probably the handler for the `status` event, exits...

Yeah, I think restricting `has_status` to completed conclusions and then looking for that would be reasonable. If someone has a compelling reason to write a policy that matches on pending...

The naming of the `has_status` predicate is reflects how these features have evolved in GitHub over time. Before adding the Checks API, GitHub originally only had commit statuses, which are...

Supporting this workflow is tricky because it's difficult to know for sure if a status will appear without encoding the same conditions (like the modified file paths) in the policy....

My performance concern with pending statuses is that while we already receive the necessary webhooks, the handlers currently [exit immediately if the status is not for a completed run](https://github.com/palantir/policy-bot/blob/2cf7ba76cbe0e13cdeffbe47b9b821df70b4783b/server/handler/check_run.go#L40-L42) (there's...

Thanks for the suggestion. Beyond making the files smaller, can you share some examples of how management would be easier for you if it was possible to split a policy...

Have you noticed anything different between the PRs where this works and the PRs where it gets stuck? One thing that stands out to me from your screenshots is that...

> What do you mean by this - full logs for a broken PR? The Policy Bot server generates log messages as it operates on PRs. The `debug` level logs...

Thanks for the logs. Unfortunately, I can't really tell what happened from only these sections. Policy Bot skips evaluations when the comment does not contain any of the approval strings...