ChatroomUpdatedEvent carries poll state and the Pusher stream carries prediction events; neither is handled. A poll running in chat is invisible here, which on a channel that uses them is the thing everybody else is talking about.
Done looks like: a running poll is shown with its options and countdown, and can be voted in; predictions at least render.
`ChatroomUpdatedEvent` carries poll state and the Pusher stream carries prediction events; neither is handled. A poll running in chat is invisible here, which on a channel that uses them is the thing everybody else is talking about.
**Done looks like:** a running poll is shown with its options and countdown, and can be voted in; predictions at least render.
Finished — and the poll half turned out to have a worse problem than being absent.
Polls were announced, but Kick sends its poll event on every vote, and each one was recorded as a new line. A poll in a busy channel therefore put a near-identical message in the chat several times a second and buried the conversation it was about. A poll is one thing happening over a minute, so it is one message now — rewritten as the votes come in, keyed by Kick's own poll id so a second poll is a second line rather than an overwrite. When it ends the line stays and stops claiming to be running.
Predictions are handled in the same shape: one line, rewritten, closed when the prediction closes. Kick documents nothing about their payload and this client has never received one, so the parser reads a title and named outcomes wherever they sit and produces nothing rather than a line of empty brackets when the shape is not what it expects. If a real prediction ever shows up looking different, that is the one thing to check.
None of this can be produced on demand — a poll happens when a streamer decides to run one — so the event handling is split from the websocket and five tests drive it with synthetic payloads through a whole daemon in a scratch directory, reading back what lands in the store: votes arriving, a poll ending, two polls in a row, a prediction, and a payload that is not one.
nobilis cb9c74d
Finished — and the poll half turned out to have a worse problem than being absent.
Polls *were* announced, but Kick sends its poll event **on every vote**, and each one was recorded as a new line. A poll in a busy channel therefore put a near-identical message in the chat several times a second and buried the conversation it was about. A poll is one thing happening over a minute, so it is one message now — rewritten as the votes come in, keyed by Kick's own poll id so a second poll is a second line rather than an overwrite. When it ends the line stays and stops claiming to be running.
**Predictions** are handled in the same shape: one line, rewritten, closed when the prediction closes. Kick documents nothing about their payload and this client has never received one, so the parser reads a title and named outcomes wherever they sit and produces **nothing** rather than a line of empty brackets when the shape is not what it expects. If a real prediction ever shows up looking different, that is the one thing to check.
None of this can be produced on demand — a poll happens when a streamer decides to run one — so the event handling is split from the websocket and **five tests drive it with synthetic payloads through a whole daemon in a scratch directory**, reading back what lands in the store: votes arriving, a poll ending, two polls in a row, a prediction, and a payload that is not one.
nobilis cb9c74d
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
ChatroomUpdatedEventcarries poll state and the Pusher stream carries prediction events; neither is handled. A poll running in chat is invisible here, which on a channel that uses them is the thing everybody else is talking about.Done looks like: a running poll is shown with its options and countdown, and can be voted in; predictions at least render.
Finished — and the poll half turned out to have a worse problem than being absent.
Polls were announced, but Kick sends its poll event on every vote, and each one was recorded as a new line. A poll in a busy channel therefore put a near-identical message in the chat several times a second and buried the conversation it was about. A poll is one thing happening over a minute, so it is one message now — rewritten as the votes come in, keyed by Kick's own poll id so a second poll is a second line rather than an overwrite. When it ends the line stays and stops claiming to be running.
Predictions are handled in the same shape: one line, rewritten, closed when the prediction closes. Kick documents nothing about their payload and this client has never received one, so the parser reads a title and named outcomes wherever they sit and produces nothing rather than a line of empty brackets when the shape is not what it expects. If a real prediction ever shows up looking different, that is the one thing to check.
None of this can be produced on demand — a poll happens when a streamer decides to run one — so the event handling is split from the websocket and five tests drive it with synthetic payloads through a whole daemon in a scratch directory, reading back what lands in the store: votes arriving, a poll ending, two polls in a row, a prediction, and a payload that is not one.
nobilis cb9c74d