# Real-Time Phoenix: only the first 3 responses are displayed on the console (p.101)

**URL:** <https://forum.devtalk.com/t/real-time-phoenix-only-the-first-3-responses-are-displayed-on-the-console-p-101/86278>\
**Category:** PragProg Customers\
**Tags:** book-real-time-phoenix, suggestion\
**Created:** [9 December 2022 03:58 UTC](https://forum.devtalk.com/t/real-time-phoenix-only-the-first-3-responses-are-displayed-on-the-console-p-101/86278 "2022-12-09T03:58:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![VAK](https://forum.devtalk.com/letter_avatar_proxy/v4/letter/v/e95f7d/32.png) [@VAK](https://forum.devtalk.com/u/VAK)\
**Post date:** [9 December 2022 03:58 UTC](https://forum.devtalk.com/t/real-time-phoenix-only-the-first-3-responses-are-displayed-on-the-console-p-101/86278/1 "2022-12-09T03:58:23Z")

</div>

Here is a scenario of cyclic sending messages and receiving responses via slowStatsChannel.  
The transport accepts all 5 responses, but only the first 3 responses that meet the 10s interval are displayed on the console, as seen in DevTools.  
My understanding is that a packet transaction has a lifetime, after which the packets are accepted but are not passed to the processing script. This is a tricky disconcerting point for those who are new to real-time network programming.

---

<div class="post-metadata">

**Author:** ![sb8244](https://forum.devtalk.com/user_avatar/forum.devtalk.com/sb8244/32/209_2.png) [@sb8244](https://forum.devtalk.com/u/sb8244)\
**Post date:** [5 January 2023 15:06 UTC](https://forum.devtalk.com/t/real-time-phoenix-only-the-first-3-responses-are-displayed-on-the-console-p-101/86278/2 "2023-01-05T15:06:11Z")

</div>

> [@VAK](#):
>
> My understanding is that a packet transaction has a lifetime, after which the packets are accepted but are not passed to the processing script

Just to clarify, do you mean this lifetime is implemented in Phoenix JS lib, or somewhere else?

The packets transmitted over the channel’s WebSocket are not delayed at all. It’s the request/response lifecycle that’s delayed inside of the Channel’s logic (via `Process.sleep`). So, when a message is sent, it’s going to be sent as fast as possible from client → server and server → client.

WebSocket itself does not have the concept of request/response lifecycle, so that’s all implemented by Phoenix’s libraries.