fix(napi): user_defined_rt can only be used once

[Brooooooklyn]

Fixes napi-rs async runtime restart by falling back to a default runtime after a user-defined runtime is consumed.

Previously, the user-defined Tokio runtime was take()n from its storage on first use, making it unavailable for subsequent restarts after shutdown. Since tokio::runtime::Runtime is not Clone, this change introduces a flag to track if a user-defined runtime was originally provided. If it was, and it's no longer available (i.e., already consumed and shut down), the system now gracefully falls back to creating a default Tokio runtime, preventing application crashes on restart.

---

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[graphite-app]

How to use the Graphite Merge Queue

Add the label ready-to-merge to this PR to add it to the merge queue.

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.

[Brooooooklyn]

@cursor fix clippy issue

[cursor]

I refactored the Tokio runtime creation logic in crates/napi/src/tokio_runtime.rs to enhance readability and conciseness. Specifically, I streamlined the conditional check for user-defined runtimes.

• I modified the create_runtime function in crates/napi/src/tokio_runtime.rs.
• I updated the conditional check for IS_USER_DEFINED_RT, replacing IS_USER_DEFINED_RT.get().copied().unwrap_or(false) with matches!(IS_USER_DEFINED_RT.get(), Some(true)). This change makes the code more idiomatic Rust when checking an Option<bool> value.

---

_{Learn more about Cursor Agents}

[Brooooooklyn]

@cursor Is there a race condition if multiple worker threads try to initialize a custom tokio runtime simultaneously?

[cursor]

I've been looking into the code you provided, specifically the start_async_runtime function and how OnceLock is used, by reading through the relevant files.

Based on my analysis, there is NO race condition when multiple worker threads try to initialize a custom Tokio runtime simultaneously. This is because OnceLock and LazyLock are used for USER_DEFINED_RT, IS_USER_DEFINED_RT, and RT, which guarantee that initialization happens exactly once, even with concurrent calls. Additionally, RwLock provides thread-safe access to the runtime.

While there's no race condition, I did notice a potential logical issue: if multiple threads attempt to set different custom runtimes, only the first one will succeed, and the others will be silently ignored. This isn't a race condition, but it might not be the intended behavior. You might consider documenting this behavior, adding a warning, or making it clear that subsequent calls to create_custom_tokio_runtime are no-ops.

---

_{Learn more about Cursor Agents}

[Copilot]

Pull Request Overview

This PR fixes an issue where a user-defined Tokio runtime in napi-rs could only be used once before becoming unavailable for restarts. The fix introduces a flag to track when a user-defined runtime was originally provided and falls back to a default runtime when the user-defined one is no longer available.

• Adds tracking of whether a user-defined runtime was originally provided
• Modifies runtime creation logic to fall back to default runtime after user-defined runtime is consumed
• Prevents application crashes on restart by ensuring a runtime is always available

[Brooooooklyn]

@cursoragent fix the compile error

[cursor]

I refined the logic for checking user-defined Tokio runtimes within the NAPI-RS crate. This change improves how the IS_USER_DEFINED_RT flag is accessed, ensuring more robust and idiomatic handling of its boolean value.

• I modified the create_runtime function in crates/napi/src/tokio_runtime.rs.
• I updated the access pattern for the IS_USER_DEFINED_RT OnceCell by adding .copied() after .get(). This converts Option<&bool> to Option<bool>, allowing unwrap_or(false) to operate directly on a bool value, which is a more idiomatic way to handle Copy types from an Option reference.

---

_{Learn more about Cursor Agents}