Cloud sessions batch stream events and can hold them back when nobody is watching.
The no-subscriber hold is wired but its interval defaults to 0, so it does nothing.
tengu_ccr_no_subscriber_flush_ms Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.248: not a boolean we can read
Read once, for one account on one subscription tier, against v2.1.248. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
The client that ships events for remote and cloud sessions gained a batch upload path and an awareness of whether anyone is subscribed to the stream. When the last server report said there were no subscribers, ephemeral stream events are buffered for the longer of the no-subscriber interval and the normal flush interval, and flushed immediately once a subscriber shows up. The extra delay comes from tengu_ccr_no_subscriber_flush_ms, default 0, which disables it.
- Single-event writes now go through the batch path.
- Values are clamped to 0 through 60000; a non-finite value is logged and ignored.
- Delivery reports of "received" mark subscribers as present, ending the delay early.
- Consecutive
thinking_tokenssystem events in the buffer are merged, summing their estimated token deltas.
setNoSubscriberStreamEventFlushIntervalMs
Strings lifted out of the shipped bundle, so the claim above can be checked against them.