---
id: PLAY-3
family: RT-PLAY
level: core
profiles: [runtime, editor-client]
posture: normative-target
added: "1.0"
changed: "1.0"
source: https://flowdrop.io/spec/rules/rt-play/play-3
specification: FlowDrop Workflow Specification 1.0-draft
licence: CC BY 4.0
---

# PLAY-3 — The message poll has its own envelope, with the flags at the top level

*RT-PLAY (Part II) · level: core · profiles: runtime, editor-client · added in 1.0*

The three flags beside the data are what a polling client reads to decide whether to fetch again and whether the turn is over. Folding them into the shared pagination block would break every such client.

## The rule

> **Normative.** This is the rule.
>
> 1. The message poll answers `{success, data, hasMore, hasOlder, sessionStatus}` in that order, with no pagination block and no `has_more` key: the three flags are siblings of `data`, not nested.
>
> 2. `hasMore` reports page fullness (whether the page returned as many messages as were asked for) and is an inference.
>
> 3. `hasOlder` is authoritative: it reports whether messages older than the page exist, so a client scrolling back never pays a speculative empty fetch at an exact page boundary.
>
> 4. `sessionStatus` rides along so a poller needs no second request to learn the turn has finished.
>
> 5. The forward and backward cursors are honoured only when they are strings of digits; a cursor that is not is ignored, not refused.

## Related rules

- Names: PLAY-4
- Referenced by: PLAY-4

---

Rule identifiers are permanent and are never renumbered. This specification carries
no implementation status: each implementation publishes its own standing against
these rules. Licensed CC BY 4.0.