Skip to content

refactor(linter/plugins): add debug assert for passing data from NAPI callback#16465

Merged
graphite-app[bot] merged 1 commit intomainfrom
12-03-refactor_linter_plugins_add_debug_assert_for_passing_data_from_napi_callback
Dec 3, 2025
Merged

refactor(linter/plugins): add debug assert for passing data from NAPI callback#16465
graphite-app[bot] merged 1 commit intomainfrom
12-03-refactor_linter_plugins_add_debug_assert_for_passing_data_from_napi_callback

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Dec 3, 2025

Alternative to #16463.

I think I've understood the situation now, and why Brooooklyn's original code ignored the result of tx.send().

It is genuinely impossible for the call to tx.send() to fail, and that doesn't depend on there not being a bug in NAPI-RS - it's provable just from looking at the code in these functions, regardless of what NAPI-RS may do.

Add comments explaining why we can safely ignore the result of tx.send(), and add a debug_assert! just to make sure.

We want to absolutely minimize the overhead of moving between JS and Rust, so I think it's appropriate to leave out error handling for impossible cases like these.

Copy link
Member Author

overlookmotel commented Dec 3, 2025


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@overlookmotel overlookmotel marked this pull request as ready for review December 3, 2025 19:00
Copilot AI review requested due to automatic review settings December 3, 2025 19:00
@overlookmotel
Copy link
Member Author

@camc314 I actually think Broooklyn was right all along (surprise!). So IMO this solution is better.

@camc314
Copy link
Contributor

camc314 commented Dec 3, 2025

@camc314 I actually think Broooklyn was right all along (surprise!). So IMO this solution is better.

makes sense to me!

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR refactors error handling in NAPI callback wrappers by replacing ignored tx.send() results with explicit debug assertions. The change adds documentation explaining why these calls cannot fail and validates the assumption with debug_assert! in debug builds, while maintaining zero overhead in release builds for these performance-critical JS-to-Rust boundaries.

  • Replaces let _ = tx.send(result) with explicit result handling and debug assertions
  • Adds detailed comments explaining the impossibility of tx.send() failures
  • Applies the same pattern to both setupConfigs and lintFile callback wrappers

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@overlookmotel overlookmotel added the 0-merge Merge with Graphite Merge Queue label Dec 3, 2025
Copy link
Member Author

overlookmotel commented Dec 3, 2025

Merge activity

… callback (#16465)

Alternative to #16463.

I think I've understood the situation now, and why Brooooklyn's original code ignored the result of `tx.send()`.

It is genuinely impossible for the call to `tx.send()` to fail, and that doesn't depend on there not being a bug in NAPI-RS - it's provable just from looking at the code in these functions, regardless of what NAPI-RS may do.

Add comments explaining why we can safely ignore the result of `tx.send()`, and add a `debug_assert!` just to make sure.

We want to absolutely minimize the overhead of moving between JS and Rust, so I think it's appropriate to leave out error handling for impossible cases like these.
@graphite-app graphite-app bot force-pushed the 12-03-docs_linter_plugins_improve_comment_on_error_branch branch from 3544a69 to 467cc1a Compare December 3, 2025 19:09
@graphite-app graphite-app bot force-pushed the 12-03-refactor_linter_plugins_add_debug_assert_for_passing_data_from_napi_callback branch from d6b2ae6 to f9c883e Compare December 3, 2025 19:10
@graphite-app graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Dec 3, 2025
Base automatically changed from 12-03-docs_linter_plugins_improve_comment_on_error_branch to main December 3, 2025 19:20
@graphite-app graphite-app bot merged commit f9c883e into main Dec 3, 2025
19 checks passed
@graphite-app graphite-app bot deleted the 12-03-refactor_linter_plugins_add_debug_assert_for_passing_data_from_napi_callback branch December 3, 2025 19:20
taearls pushed a commit to taearls/oxc that referenced this pull request Dec 11, 2025
… callback (oxc-project#16465)

Alternative to oxc-project#16463.

I think I've understood the situation now, and why Brooooklyn's original code ignored the result of `tx.send()`.

It is genuinely impossible for the call to `tx.send()` to fail, and that doesn't depend on there not being a bug in NAPI-RS - it's provable just from looking at the code in these functions, regardless of what NAPI-RS may do.

Add comments explaining why we can safely ignore the result of `tx.send()`, and add a `debug_assert!` just to make sure.

We want to absolutely minimize the overhead of moving between JS and Rust, so I think it's appropriate to leave out error handling for impossible cases like these.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-cli Area - CLI A-linter Area - Linter C-cleanup Category - technical debt or refactoring. Solution not expected to change behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants