fix(NATSRS-002): CU-86akbhg13 publish() unwrap() panics on send failure instead of propagating an error

[flamingo]

Closes findings from rule NATSRS-002 — publish() unwrap() panics on send failure instead of propagating an error.

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	🟢 90 high	publish() unwrap() panics on send failure instead of propagating an error	async-nats/src/jetstream/consumer/push.rs:158

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: cfb21c27-56cf-4a3e-bbfe-02ce27b8b29b

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-86akbhg13 Code review fixes: NATS async-nats and CI review findings (3 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

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

[flamingo]

🦩 🟠 publish() unwrap() panics on send failure instead of propagating an error

In impl futures_util::Stream for Messages::poll_next (push.rs), replaced the client.publish(subject, Bytes::from_static(b"")).await.unwrap() call inside the spawned heartbeat-response task with an if let Err(err) = ... { tracing::warn!(...) } pattern, matching the suggested fix exactly. This prevents a panic in the detached tokio task on publish failure and instead logs the error via tracing::warn!, consistent with the sibling Ordered::poll_next heartbeat handler which already used .ok() to swallow errors non-fatally. Note: the error is still not propagated through MessagesError/the Stream's Item type (as the finding's title suggests would be ideal), since doing so would require restructuring the poll loop to track a pending publish future — this minimal fix satisfies the concrete suggested fix and eliminates the panic risk, but full error propagation to the stream consumer is not implemented.

🤖 Prompt for AI agents

In async-nats/src/jetstream/consumer/push.rs around line 158, review and complete this code-review fix: publish() unwrap() panics on send failure instead of propagating an error.
What the draft fix changed: In `impl futures_util::Stream for Messages::poll_next` (push.rs), replaced the `client.publish(subject, Bytes::from_static(b"")).await.unwrap()` call inside the spawned heartbeat-response task with an `if let Err(err) = ... { tracing::warn!(...) }` pattern, matching the suggested fix exactly. This prevents a panic in the detached tokio task on publish failure and instead logs the error via `tracing::warn!`, consistent with the sibling `Ordered::poll_next` heartbeat handler which already used `.ok()` to swallow errors non-fatally. Note: the error is still not propagated through `MessagesError`/the Stream's `Item` type (as the finding's title suggests would be ideal), since doing so would require restructuring the poll loop to track a pending publish future — this minimal fix satisfies the concrete suggested fix and eliminates the panic risk, but full error propagation to the stream consumer is not implemented.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟢 90 high — react 👍/👎 to teach the reviewer