Support Bugzilla needinfo webhooks - #6558
Conversation
| """Inbound Phabricator and Bugzilla webhooks that trigger Hackbot runs. | ||
|
|
||
| Starts with Phabricator: an ``@hackbot`` mention in a comment on a Differential | ||
| revision triggers a bug-fix follow-up run against that revision. Authenticated | ||
| by Phabricator's HMAC signature (not the ``X-API-Key`` the other routes use), so | ||
| this lives on its own router without ``require_api_key``. | ||
| For Phabricator, an ``@hackbot`` mention on a Differential revision triggers a | ||
| follow-up run. For Bugzilla, a structured ``flag.needinfo`` modification aimed | ||
| at Hackbot triggers a bug-based follow-up. Each endpoint uses its webhook's own | ||
| authentication rather than the public API's ``X-API-Key``. |
There was a problem hiding this comment.
Let's make it generic, so we do not need to update on every webhook we support.
| _seen_bugzilla_events: TTLCache = TTLCache( | ||
| maxsize=4096, ttl=settings.bugzilla_webhook.dedupe_ttl_seconds | ||
| ) |
There was a problem hiding this comment.
This will not work. This is a stateless service. Two requests could be handled with two different instances, then the cache will be different.
There was a problem hiding this comment.
We could do DB-level de-duplication that we could even use for different use cases, not only this.
I will file an issue for that.
There was a problem hiding this comment.
Good catch. The Phabricator cache _seen_transactions also has the same limitation.
There was a problem hiding this comment.
Yes, but that one is used only for performance concerns and reduce notwork requests, not as a source of truth, so it will not impact the end results.
Co-authored-by: Suhaib Mujahid <suhaibmujahid@gmail.com>
2 participants
Summary
bug-fixrun when a public bug receivesneedinfo?(hackbot@mozilla.tld).Resolve #6469