feat(eslint): Add no-return-await rule to eslint config
#8388
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AbhiPrasad
requested review from
a team,
stephanie-anderson and
Lms24
and removed request for
a team
Lms24
approved these changes
Jun 23, 2023
There was a problem hiding this comment.
Well, TIL 😅 Didn't even think about this before but it makes a lot of sense. I Agree with your stack trace point. IIUC this would only be problematic in case a stack frame from our SDK code would be of interest for our users. I don't see this being much of a problem but as you said, we can revisit on a case-by-case basis.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add https://eslint.org/docs/latest/rules/no-return-await to eslint config to remove usage of uneeded async/await calls. This helps reduce microtasks being generated, which can help reduce memory pressure caused by the SDK.
The downside of removing
return awaitis that stacktraces get slightly worse for async errors that use these methods, as we no longer pause execution on return for the engine to grab context on, but instead just pass through the promise, but I think it's worth it for this to be the default, and for us to opt-in to the better stacktraces if need be.