fix(realtime): handle response_cancel_not_active as non-fatal

[omChauhanDev]

Please describe the changes in your PR. If it is addressing an issue, please reference that as well.

Fixes #3755

Change : response_cancel_not_active errors from the API are now logged as warnings instead of fatally killing the ws connection in realtime services.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/pipecat/services/grok/realtime/llm.py	0.00%	3 Missing ⚠️
...rc/pipecat/services/openai_realtime_beta/openai.py	0.00%	3 Missing ⚠️

Files with missing lines	Coverage Δ
src/pipecat/services/openai/realtime/llm.py	0.00% <ø> (ø)
src/pipecat/services/grok/realtime/llm.py	0.00% <0.00%> (ø)
...rc/pipecat/services/openai_realtime_beta/openai.py	0.00% <0.00%> (ø)

... and 97 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kollaikal-rupesh]

Nice fix! The approach is correct — response_cancel_not_active should definitely not be fatal.

One minor suggestion: consider using logger.debug() instead of logger.warning() here. This error is an expected, benign condition in push-to-talk mode — every time the user presses the button while the bot is idle, this will fire. Using warning could create log noise in production for something that's completely normal. debug would be more appropriate for an expected code path.

Also, minor style nit: the pipecat convention for log messages typically prefixes with {self} for service identification, e.g.:

logger.debug(f"{self} {evt.error.message}")

[markbackman]

This was suggested already, but this should be debug. If it's a warning, it'll draw undue attention since it's a normal outcome of using the API.

[omChauhanDev]

make sense, done

[markbackman]

LGTM! Just a small comment to resolve before merging.