Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: make async webhooks fully async #3111

Merged
merged 1 commit into from Feb 17, 2023
Merged

Conversation

zepatrik
Copy link
Member

Related issue(s)

The current approach does not ignore errors from the request building process, only the actual request. This patch moves the request build into the async part of the webhook as well.

Checklist

  • I have read the contributing guidelines.
  • I have referenced an issue containing the design document if my change
    introduces a new feature.
  • I am following the
    contributing code guidelines.
  • I have read the security policy.
  • I confirm that this pull request does not address a security
    vulnerability. If this pull request addresses a security vulnerability, I
    confirm that I got the approval (please contact
    security@ory.sh) from the maintainers to push
    the changes.
  • I have added tests that prove my fix is effective or that my feature
    works.
  • I have added or changed the documentation.

Further Comments

_

Copy link
Member Author

@zepatrik zepatrik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly don't know how tests passed before...

Kinda buggy before, but the bugs did not surface.

@@ -332,40 +343,30 @@ func (e *WebHook) execute(ctx context.Context, data *templateContext) error {
if canInterrupt || parseResponse {
if err := parseWebhookResponse(resp, data.Identity); err != nil {
span.SetStatus(codes.Error, err.Error())
errChan <- err
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After this there is no return, so another error would be send.

}

if parseResponse {
if err := parseWebhookResponse(resp, data.Identity); err != nil {
span.SetStatus(codes.Error, err.Error())
errChan <- err
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, after the error nil is send.

return nil
}

return <-errChan
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This always waits for one message on the channel, I don't understand how it could even run async as this is blocking AND racy with the go routine also reading from that channel 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh it would return in the if above...

@zepatrik zepatrik marked this pull request as ready for review February 16, 2023 14:56
@codecov
Copy link

codecov bot commented Feb 16, 2023

Codecov Report

Merging #3111 (1f15c86) into master (59f35d1) will increase coverage by 0.00%.
The diff coverage is 97.72%.

❗ Current head 1f15c86 differs from pull request most recent head 4f60b2d. Consider uploading reports for the commit 4f60b2d to get more accurate results

@@           Coverage Diff           @@
##           master    #3111   +/-   ##
=======================================
  Coverage   77.57%   77.57%           
=======================================
  Files         315      315           
  Lines       19962    19963    +1     
=======================================
+ Hits        15486    15487    +1     
  Misses       3285     3285           
  Partials     1191     1191           
Impacted Files Coverage Δ
selfservice/hook/web_hook.go 78.86% <97.72%> (+0.08%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Copy link
Contributor

@jonas-jonas jonas-jonas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice! Looks a lot cleaner as well, IMO.

Comment on lines +363 to +370
if !ignoreResponse {
return makeRequest()
}
go func() {
// we cannot handle the error as we are running async, and it is logged anyway
_ = makeRequest()
}()
return nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if !ignoreResponse {
return makeRequest()
}
go func() {
// we cannot handle the error as we are running async, and it is logged anyway
_ = makeRequest()
}()
return nil
if ignoreResponse {
go func() {
// we cannot handle the error as we are running async, and it is logged anyway
_ = makeRequest()
}()
return nil
}
return makeRequest()

Just a nit. I like positive branching. But not sure that it improves this much. It's fine either way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm I typically go for shorter branches in the if body, as that makes it easier to read.

Comment on lines +315 to +320
req, err := builder.BuildRequest(ctx, data)
if errors.Is(err, request.ErrCancel) {
return nil
} else if err != nil {
return err
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This prints the kratos cli usage help if, the jsonnet is invalid:
image

I guess it did that before, but can we improve that somehow?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we can do that but separately. I guess it does not hurt though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants