Conversation
…CC-1066) The cap was documented as closing the agent's connection, with the bot "receiving a connection error the next time it tries to send or receive data". That has never been true for HTTP transports: the platform's /bot request is a one-shot POST, so the bot never reads or writes on it again and observes nothing at all. The session simply carried on past its limit. Base image 0.1.27 enforces the limit inside the bot process instead, so the described outcome now actually happens. Reword the four places that described the old mechanism, and add a version note for anyone on an older base image whose sessions currently overrun.
|
🔍 Mintlify preview for this branch: https://daily-pcc-1066.mintlify.site |
cbrianhill
left a comment
cbrianhill
left a comment
There was a problem hiding this comment.
A couple of minor comments for clarity, but this overall looks great.
| <ParamField path="max_session_duration" type="number" default="7200"> | ||
| Maximum session duration in seconds. When a session reaches this limit, the | ||
| agent's connection is forcibly closed — the session is cut off mid-flight | ||
| with no notice to the bot. Valid range: `60` to `14400` (4 hours). See | ||
| [Session duration limits](/pipecat-cloud/fundamentals/active-sessions#session-duration-limits) | ||
| for more information. | ||
|
|
||
| ```toml | ||
| max_session_duration = 300 | ||
| ``` | ||
|
|
||
| </ParamField> |
There was a problem hiding this comment.
Should this section be updated for consistency with the above?
| This is a platform-level safeguard, not a polite signal. The pipeline unwinds cleanly — each processor's `cleanup()` runs — but the bot gets no opportunity to say anything first. If you want it to say goodbye before the cap, implement your own timer in bot code that fires slightly earlier. | ||
|
|
||
| <Note> | ||
| Enforcing the limit inside the bot process requires **base image 0.1.27 or | ||
| later**. On older base images the limit only closes the platform's connection | ||
| to your bot, which a bot using an HTTP transport (for example a Daily/WebRTC | ||
| room) cannot observe — so the session keeps running past its limit. If your | ||
| agent relies on that, raise `maxSessionDuration` before upgrading. | ||
| </Note> |
There was a problem hiding this comment.
Should we point out that the invocation of cleanup() only applies if the bot uses PipelineRunner()? The comments in the implementation indicate the behavior isn't unconditional. But I don't know whether there are customers who avoid our runner classes.
| to your bot, which a bot using an HTTP transport (for example a Daily/WebRTC | ||
| room) cannot observe — so the session keeps running past its limit. If your |
There was a problem hiding this comment.
The term 'HTTP transport' doesn't seem quite correct to me. Aren't we really talking about HTTP-activated bots? (i.e. an HTTP request starts the session, and then the bot configures its own transports for media)
- The pcc-deploy.toml `max_session_duration` field had the same stale description as the CLI flag and was missed the first time. - `cleanup()` running is conditional: PipelineRunner absorbs the cancellation and unwinds the pipeline, but a bot that doesn't use it just sees a CancelledError wherever it was awaiting. Say so rather than promising cleanup unconditionally. - "HTTP transport" conflated activation with media. The HTTP request only starts the session; the bot then connects its own media transport, which is exactly why closing that request told it nothing.
|
All three addressed. The
"HTTP transport" — agreed, and it's a better catch than a wording nit. The HTTP request only starts the session; the bot then connects its own media transport. That distinction is precisely why the old behaviour was broken — we were closing the activation request and expecting a bot to notice, when the thing carrying its audio was somewhere else entirely. Reworded here, and in the base-image code comments (daily-co/pipecat-cloud-images#102), which had inherited the same sloppiness from me. Also normalised the one-line descriptions in |
4 participants
Docs half of PCC-1066. Companion to pipecat-cloud-images#102.
Why
The cap was documented as closing the agent's connection, with the bot "receiving a connection error the next time it tries to send or receive data".
That has never been true for HTTP transports. The platform's
/botrequest is a one-shot POST — the bot never reads or writes on it again, so closing it produces no error the bot can observe and the session simply carries on past its limit. That gap is the bug behind PCC-1066: a customer's session ran ~43 minutes past a 2-hour cap while a second session was placed into the same process.Base image
0.1.27enforces the limit inside the bot process, so the outcome the docs already described now actually happens. This PR fixes the four places that described the old mechanism.Changes
pipecat-cloud/fundamentals/active-sessions.mdx— rewritten to say the bot is cancelled and the pipeline shuts down. Keeps the "not a polite signal / use your own timer" guidance, which is still correct, and adds that the pipeline unwinds cleanly (cleanup()runs on each processor) since that is now true and worth knowing. Adds a version note for anyone on an older base image whose sessions currently overrun — they should raisemaxSessionDurationbefore upgrading.api-reference/cli/cloud/deploy.mdx,openapi.json(create + update request schemas) — same correction to the one-line description.pipecat/learn/pipeline-termination.mdx— the cross-reference note.Left alone: the
maxSessionDurationresponse field description inopenapi.json, which describes the configured value rather than the behaviour.Sequencing
Safe to merge independently, but the version note names 0.1.27 — ideally land after images#102 is released so the reference is live.