Weighted as backend-weight3 , since the implementation as described in the description is straightforward, but would require a new column on the logs table.
Just cross-linking this related issue #14888 which is similar, but additionally suggests adding a X-Attempt-Number header which would increment with each retry.
Hi @.luke! I started looking at this and would love to take it on if you'll are still looking for community contributions.
I was going to check in on this first before I started... but I was looking through it this weekend, got carried away, and just more or less completed the ticket. I have a couple outstanding items to look through before I take it out of draft, but the current work is up at !160952 (merged).
@m_frankiewicz We have a wonderful Community contribution for this feature in review. It compliments nicely the recent work to resend failed webhooks via the API. With this feature, webhook receivers will have a way to identify webhooks that they have already handled when retrying them.
My pleasure @m_frankiewicz@.luke! I appreciate all the help with this! I see that !151130 (merged) has been open for a bit; if there are any concerns about conflicts, I'm happy to have !151130 (merged) go in first and take care of those conflicts in my branch. Thanks!
@.luke@m_frankiewicz sure thing! I'm actually looking for more tickets like this that are either delivering a feature or are more complex than a simple chore/bug. I'm finding most issues tagged with Seeking community contributions are on the smaller side. Are there any more features like this on the wishlist? Either in the Webhooks topic, or anywhere else?
@van.m.anderson Magda is the product manager, so she does trump me somewhat but on my personal list of topics that I think would have a good impact in areas that our group are not prioritising currently are:
@.luke the HMAC ticket (#19367) looks really cool! Your implementation plan makes sense, and after looking through the slack docs and slack Webhook UI, I have a good idea of how to move forward. I imagine we will have the existing user secret token field along side the signing secret field, send both headers, and encourage users to use the X-Gitlab-Signature rather than X-Gitlab-Token. That way we support both approaches. I'm also thinking it might make sense to follow suit with the slack implementation and use a timestamp header for HMAC key.
For something like this, I would want to open a POC MR without any tests to check that the implementation is on the right track. Once the POC is up, it might also make sense to proceed with multiple PRs if we can draw some clear dividing lines around changes.
@van.m.anderson Yes, that sounds great! I agree that we need to continue to support the old token header, but encourage people to move the the new digest token instead. Slack have "deprecated" their old token and we could do the same to encourage people to use the digest version, but really, most likely continue to support it because we don't want to break people's integrations . I like the Slack implementation also .
I think push a pure POC is a really sensible idea Thank you!