fix(uptime): clean up some recv() usage and vec allocs

[klochek]

No description provided.

[sentry]

Bug: The pending_items counter is not decremented for items in the final batch, leading to inaccurate metrics after channel closure.
_{Severity: HIGH | Confidence: High}

🔍 Detailed Analysis

The producer.pending_items counter is incremented for every message but not consistently decremented. Specifically, when the channel closes and recv_many() returns 0, any remaining items in the batch are sent via the final if !batch.is_empty() block (lines 111-118) without a corresponding pending_items.fetch_sub() call. This asymmetry causes the producer.pending_items gauge to retain a non-zero value, equal to the number of items in the final batch, even after all items have been processed and sent, leading to inaccurate monitoring data.

💡 Suggested Fix

Ensure pending_items.fetch_sub(batch.len(), Ordering::Relaxed) is called for the final batch sent at lines 111-118, similar to how full batches are handled.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/producer/vector_producer.rs#L108-L114

Potential issue: The `producer.pending_items` counter is incremented for every message
but not consistently decremented. Specifically, when the channel closes and
`recv_many()` returns 0, any remaining items in the `batch` are sent via the final `if
!batch.is_empty()` block (lines 111-118) without a corresponding
`pending_items.fetch_sub()` call. This asymmetry causes the `producer.pending_items`
gauge to retain a non-zero value, equal to the number of items in the final batch, even
after all items have been processed and sent, leading to inaccurate monitoring data.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 4971860}