fix(async): prevent missed async errors in try/catch with return-await ESLint rule

[amsminn]

TLDR

Added @typescript-eslint/return-await ESLint rule to enforce
proper async/await usage in try-catch blocks, preventing errors
from bypassing catch handlers. Also cleaned up unnecessary
return await in non-try-catch contexts.

Dive Deeper

The rule addresses a subtle but important anti-pattern where
returning promises directly in try-catch blocks causes async
errors to escape the catch handler

// Before: Error bypasses catch
try {
  return someAsyncFunc();
} catch (e) {
  // Never called for async errors
}

// After: Error properly caught
try {
  return await someAsyncFunc();
} catch (e) {
  // Handles async errors correctly
}

This PR includes:

1. ESLint config update with the new rule
2. Fixed 15 files to add required await in try-catch blocks
3. Removed unnecessary return await in regular async contexts

Reviewer Test Plan

1. Run npm run lint - should pass without errors
2. Check modified files for proper async/await usage

Testing Matrix

	🍏	🪟	🐧
npm run	✅	❓	❓
npx	✅	❓	❓
Docker	❓	❓	❓
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

• This PR Resolves on Potential async error handling issues #8167

[gemini-code-assist]

Summary of Changes

Hello @amsminn, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the robustness of asynchronous error handling and improves code quality across the codebase. By introducing a new ESLint rule and applying its fixes, it ensures that asynchronous errors are reliably caught in try-catch blocks and eliminates redundant await keywords where they are not needed, leading to cleaner and more predictable asynchronous code execution.

Highlights

• ESLint Configuration Update: The ESLint configuration has been updated to include the @typescript-eslint/return-await rule. This rule enforces proper async/await usage, specifically requiring await when returning promises within try-catch blocks to ensure errors are properly handled, and disallowing unnecessary await in other return statements.
• Improved Async Error Handling: Several files have been modified to add the necessary await keyword in return statements within try-catch contexts. This prevents async errors from bypassing catch handlers, ensuring more robust error management.
• Code Cleanliness and Performance: Unnecessary return await patterns have been removed from various files outside of try-catch contexts. This change improves code readability and slightly optimizes performance by avoiding redundant promise unwrapping.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly introduces and applies the @typescript-eslint/return-await ESLint rule to enforce safer async patterns within try/catch blocks. The changes effectively prevent potential unhandled promise rejections, improving the robustness of error handling. The accompanying cleanup of redundant await statements in other contexts is also a welcome improvement for code clarity and consistency. I've identified one pre-existing critical security vulnerability related to command injection in a file that was modified, which I've detailed in a comment.

[skeshive]

hmm I'm seeing local test failures due to this- can you double check this change?

[amsminn]

On my local machine, running test didn’t show any test failures related to edit.ts.
However, I did find an issue in editor.ts in the Test (macos-latest, 20.x) test run.

What happened

Before, the try just returned a promise. If that promise later failed, it happened outside the try/catch, so the catch never ran.
With await, the try actually waits, and any error goes straight into the catch. The only issue left was that our catch logged the error but didn’t rethrow it.

Fix

I changed the catch block to log and then rethrow

catch (error) {
  console.error(error);
  throw error;
}

[gemini-code-assist]

Thank you for the detailed explanation, amsminn. Your analysis of how await affects error propagation within try/catch blocks is spot on. It's crucial to await promises within try blocks to ensure that rejections are caught by the catch block, rather than becoming unhandled promise rejections.

Furthermore, your proposed fix of rethrowing the error after logging it in the catch block is indeed the correct and recommended pattern. This ensures that while the error is recorded for debugging, it also continues to propagate up the call stack, allowing higher-level error handlers to address it if necessary. This aligns perfectly with the goal of this pull request to enforce robust async error handling.