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

Await apiHandler to handle error in try/catch #1602

Merged
merged 3 commits into from
Mar 29, 2024

Conversation

VincentClair
Copy link
Contributor

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?
  • Have you written unit tests?
  • Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
  • This PR is associated with an existing issue?

Closing issues

closes #1598

Test plan

Checks that a controller method without async keyword throwing an error is caught.

The real problem is if method is not a promise (async keyword), and error throw immediately when building promise, server is no more responding, and we get a time out (actually 5sec in tests).

The problem could resolve in two ways :

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Hello there VincentClair 👋

Thank you and congrats 🎉 for opening your first PR on this project.✨

We will review the following PR soon! 👀

@@ -103,7 +103,7 @@ export function RegisterRoutes(app: Router) {
const controller = new {{../name}}();
{{/if}}

templateService.apiHandler({
Copy link
Collaborator

@WoH WoH Mar 24, 2024

Choose a reason for hiding this comment

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

I think we can always await
@jackey8616

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agree, but function must be always async: we could replace condition {{#if ../../iocModule}}async {{/if}}line 82 by async directly.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, that was the ultimate goal, while still making ts not complain about it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can always await @jackey8616

Yes, I think that's good.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done


try {
const promise = this.buildPromise(methodName, controller, validatedArgs);
const data = await Promise.resolve(promise);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

is Promise.resolve mandatory : promise ca be waited directly, no? const data = await promise;

Copy link
Collaborator

Choose a reason for hiding this comment

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

No, remove it, assuming this.buildPromise never returns anything but a Promise

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@VincentClair VincentClair force-pushed the fix/1598-error-handler-middleware branch from 6b8c611 to 03efb05 Compare March 26, 2024 09:00
@VincentClair
Copy link
Contributor Author

Hello @WoH @jackey8616,
How can i help to validate this PR ? Is there something missing ?

Copy link
Collaborator

@WoH WoH left a comment

Choose a reason for hiding this comment

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

No, lgtm 🚀

@WoH WoH merged commit 612b1c9 into lukeautry:master Mar 29, 2024
18 checks passed
@VincentClair VincentClair deleted the fix/1598-error-handler-middleware branch April 11, 2024 06:07
@denizdogan
Copy link

When can we expect a new release with this fix included? Much appreciated

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.

ErrorHandlerMiddleware is ignore with 6.1.*
4 participants