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

[gitlab] get rid of UnhandledPromiseRejectionWarning #10148

Merged
merged 1 commit into from
Jun 8, 2022
Merged

Conversation

AlexTugarev
Copy link
Member

@AlexTugarev AlexTugarev commented May 20, 2022

This PR fixes several issues with the GitLab webhook receiver:

  • clean up of logs: less pollution, and no UnhandledPromiseRejectionWarning
  • align with webhook implementation recommendation: avoid receiving double events on 501 responses or requests taking too long to be processed
[gitlab] webhook receiver clean-up and fixing UnhandledPromiseRejectionWarning

@AlexTugarev AlexTugarev requested a review from a team May 20, 2022 09:28
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label May 20, 2022
res.send();
return;
try {
const event = req.header("X-Gitlab-Event");
Copy link
Contributor

Choose a reason for hiding this comment

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

Does Gitlab send any kind of signature with the payload that we should verify, like Github does?

Copy link
Member Author

Choose a reason for hiding this comment

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

@easyCZ
Copy link
Member

easyCZ commented May 24, 2022

Thanks for the PR. Would it make sense to write a test case for this?

@AlexTugarev
Copy link
Member Author

Thanks for the PR. Would it make sense to write a test case for this?

@easyCZ, yes, sure. Is this a general question, do you want want to help, or do you want me to create one?
How far should we go? Extracting the operation for which this PR adds a guard, or creating a whole mocked http server.

@easyCZ
Copy link
Member

easyCZ commented May 24, 2022

Thanks for the PR. Would it make sense to write a test case for this?

@easyCZ, yes, sure. Is this a general question, do you want want to help, or do you want me to create one? How far should we go? Extracting the operation for which this PR adds a guard, or creating a whole mocked http server.

Sorry, I should've been clearer. Normally, when you encounter a 3rd party integration behaviour which is unexpected, it's useful to add a regression test to ensure the special treatment doesn't get undone without necessary context. It also helps as documentation of the behaviour.

My question was more how difficult it would be for you to add it, or whether you feel it is necessary for this case.

@geropl
Copy link
Member

geropl commented Jun 1, 2022

@easyCZ I stongly agree that we should have tests for integrations, but I don't want to disturb focus now, and feel it's out-of scope for this PR.

@AlexTugarev Could could you rebase + add a couple of lines of comments as to why the changes are necessary/how GitLab behaves? 🙏

@geropl geropl self-assigned this Jun 1, 2022
Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

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

Fixes the issue at hand! 👍

/hold because of this comment: Please add a couple of lines about the why

@AlexTugarev
Copy link
Member Author

@geropl, thanks for the pointer, while updating the PR description as requested rightly, I took a change to strictly follow the recommendations on webhook receiver implementations, thus rewrote the part again to make it clean.

});

span.finish();
res.status(201).send("Prebuild request handled.");
Copy link
Member Author

Choose a reason for hiding this comment

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

BTW, this actually can be used to check the handling of the event on GitLab's side. quite handy!

the 201 is to signal the async handling on Gitpod's side.

@AlexTugarev AlexTugarev requested a review from geropl June 7, 2022 12:28
@@ -32,49 +32,55 @@ export class GitLabApp {

@postConstruct()
protected init() {
/**
* see https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#configure-your-webhook-receiver-endpoint
Copy link
Member

Choose a reason for hiding this comment

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

🧡

Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

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

👍

@AlexTugarev
Copy link
Member Author

/hold cancel

@roboquat roboquat merged commit 07f7d2e into main Jun 8, 2022
@roboquat roboquat deleted the at/gitlab-app branch June 8, 2022 13:45
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note size/M team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants