Skip to content

fix(NATSRS-008-3): CU-86akbhh82 2 review findings across 2 files - #140

Draft
flamingo[bot] wants to merge 2 commits into
mainfrom
ai-fix/natsrs-008-3-919db230-4fa2224e
Draft

flamingo[bot] wants to merge 2 commits into
mainfrom
ai-fix/natsrs-008-3-919db230-4fa2224e

Conversation

@flamingo

@flamingo flamingo Bot commented Sep 14, 2026

Copy link
Copy Markdown

Closes 2 review findings across 2 files.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

# Fix confidence Finding Location
1 🟡 85 medium unwrap() on reply subject in service verb dispatch loop can panic the whole service task async-nats/src/service/mod.rs:390
2 🟡 85 medium unwrap() on publish inside spawned heartbeat responder task can panic the task silently async-nats/src/jetstream/consumer/push.rs:152

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.


Run: https://product-hub.flamingo.so/admin/code-review
Run id: 4fa2224e-8528-443d-a51a-823c78308977

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akbhh82 NATS async-nats and CI review findings (9 PRs)

@flamingo flamingo Bot left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

🦩 What this fix changed, finding by finding

2 finding(s) fixed in this draft — 2 explained inline on the diff.

version: info.version.clone(),
metadata: info.metadata.clone(),
})?;
client.publish(ping.reply.unwrap(), pong.into()).await?;

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

🦩 🟠 unwrap() on reply subject in service verb dispatch loop can panic the whole service task

In Service::add's spawned task (the tokio::select! loop handling PING/INFO/STATS verb subscriptions), replaced the three .reply.unwrap() calls with let Some(reply) = <msg>.reply else { debug!(...); continue; }; guards for the PING, INFO, and STATS branches respectively. Each branch now skips processing (via continue, logging at debug level) instead of panicking when a request lacks a reply subject, and uses the extracted reply variable for the subsequent client.publish(...) call. This prevents a malformed request from aborting the whole background service task while leaving all other behavior (response payloads, stats updates) unchanged.

🤖 Prompt for AI agents
In async-nats/src/service/mod.rs around line 390, review and complete this code-review fix: unwrap() on reply subject in service verb dispatch loop can panic the whole service task.
What the draft fix changed: In `Service::add`'s spawned task (the `tokio::select!` loop handling PING/INFO/STATS verb subscriptions), replaced the three `.reply.unwrap()` calls with `let Some(reply) = <msg>.reply else { debug!(...); continue; };` guards for the PING, INFO, and STATS branches respectively. Each branch now skips processing (via `continue`, logging at debug level) instead of panicking when a request lacks a reply subject, and uses the extracted `reply` variable for the subsequent `client.publish(...)` call. This prevents a malformed request from aborting the whole background service task while leaving all other behavior (response payloads, stats updates) unchanged.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 85 medium — react 👍/👎 to teach the reviewer

Comment on lines 153 to 166
// TODO store pending_publish as a future and return errors from it
let client = self.context.client.clone();
tokio::task::spawn(async move {
client
.publish(subject, Bytes::from_static(b""))
.await
.unwrap();
if let Err(err) =
client.publish(subject, Bytes::from_static(b"")).await
{
error!(
"failed to respond to idle heartbeat: {}",
err
);
}
});
}

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

🦩 🟠 unwrap() on publish inside spawned heartbeat responder task can panic the task silently

In Messages::poll_next (impl of futures_util::Stream for Messages), replaced the .publish(subject, Bytes::from_static(b"")).await.unwrap() call inside the spawned heartbeat-responder tokio::task::spawn with an if let Err(err) = ... { error!(...) } pattern, matching the existing non-panicking style used for the analogous flow-control publish in Ordered::poll_next (which uses .ok()). This removes the panic-on-publish-failure path while still surfacing the failure via a log line instead of silently dropping it. Added error to the tracing import list at the top of the file to support the new log call. No other behavior changed.

🤖 Prompt for AI agents
In async-nats/src/jetstream/consumer/push.rs around line 152, review and complete this code-review fix: unwrap() on publish inside spawned heartbeat responder task can panic the task silently.
What the draft fix changed: In `Messages::poll_next` (impl of `futures_util::Stream for Messages`), replaced the `.publish(subject, Bytes::from_static(b"")).await.unwrap()` call inside the spawned heartbeat-responder `tokio::task::spawn` with an `if let Err(err) = ... { error!(...) }` pattern, matching the existing non-panicking style used for the analogous flow-control publish in `Ordered::poll_next` (which uses `.ok()`). This removes the panic-on-publish-failure path while still surfacing the failure via a log line instead of silently dropping it. Added `error` to the `tracing` import list at the top of the file to support the new log call. No other behavior changed.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 85 medium — react 👍/👎 to teach the reviewer

@flamingo flamingo Bot changed the title fix(NATSRS-008-3): 2 review findings across 2 files fix(NATSRS-008-3): CU-86akbhh82 2 review findings across 2 files Sep 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants