> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/nemo/relay/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemo/relay/_mcp/server.

# Type Alias Nemo Relay Native Async Middleware Cb

> Completion-based native middleware callback.

Generated from `cargo doc --no-deps -p nemo-relay -p nemo-relay-adaptive -p nemo-relay-pii-redaction -p nemo-relay-ffi -p nemo-relay-types -p nemo-relay-plugin -p nemo-relay-worker-proto -p nemo-relay-worker`.

<pre />

Completion-based native middleware callback.

`invocation_json` is borrowed for the call. A callback that returns [`NemoRelayNativeAsyncCallbackState::Pending`](/reference/api/rust-library-reference/nemo-relay-plugin/enum-nemorelaynativeasynccallbackstate) as a `u32` owns one completion reference and must settle it then call the v3 `async_completion_release` hook. The host validates the returned discriminant. When `next` is non-null, the callback owns that handle for the invocation and must call `async_next_release` exactly once after its final use, regardless of whether it returns `Complete` or `Pending`. The host never reclaims a `next` handle after handing it to the callback. `next` is null for non-execution middleware. Relay invokes the callback on the Tokio runtime worker polling that middleware invocation, without stable OS-thread affinity; separate invocations may run concurrently. After returning `Pending`, retained completion and `next` handles may be used from a plugin-owned thread until the completion settles. Every `next` operation must finish before resolving or rejecting the completion; Relay rejects or cancels unfinished and later continuation calls. The plugin must synchronize shared `user_data` and callback state and serialize each handle's final release after its last operation returns.