Seconds instead of milliseconds
An ID a thousand times too small, which sorts before every real entry
1700000000-0
Redis Stream ID Parser
Paste stream IDs to see the time each one refers to and what its sequence number means. The special forms are explained too, because choosing the wrong one is the most common streams bug.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Parse. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The special forms
Why passing 0 to XREADGROUP re-reads the pending list forever
1700000000000-0 $ > * -
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Building an ID from a seconds timestamp
The first half is milliseconds. A seconds value is a thousand times too small, so it sorts before every real entry and XRANGE from it returns the whole stream.
Instead:Multiply by 1000, or let the server generate the ID with `*`.
Passing 0 to XREADGROUP expecting new messages
Any ID other than `>` returns that consumer's PENDING entries, so the consumer re-reads its own unacknowledged messages forever and never sees anything new.
Instead:Use `>` for new messages. Use 0 deliberately, and only to recover the pending list.
Generating IDs client-side to control ordering
Every ID has to beat the stream's current top or XADD is rejected, and coordinating that across producers is not worth doing.
Instead:XADD with `*` and let the server handle both the clock and the sequence.
An ID is a time and a tiebreak, and the special forms are not IDs at all
Stream IDs are ms-seq, where ms is a Unix millisecond timestamp taken from the server clock and seq disambiguates entries added within the same millisecond. IDs strictly increase, which is what makes range queries and consumer groups work.
The classic bug: seconds instead of milliseconds
An ID built from a seconds timestamp is a thousand times too small, so it sorts before every genuine entry in the stream. XRANGE from that ID quietly returns the entire stream rather than the recent slice you wanted, and XADD with it fails because it is smaller than the current top. The symptom is a consumer that reprocesses everything.
> and $ are not interchangeable
In XREADGROUP, > means entries never delivered to any consumer in this group. Any other ID, including 0, means that consumer's PENDING entries instead, so passing 0 makes a consumer re-read its own unacknowledged messages forever without ever seeing new ones. In XREAD, $ means only entries added after this call, and it is not valid for XREADGROUP.
A bare millisecond means different things at each end
In XRANGE, a start of 1700000000000 means sequence 0 of that millisecond, while an end of the same number means the maximum sequence. That asymmetry is deliberate and makes a bare timestamp behave as the whole millisecond. Redis 6.2 added exclusive ranges written with a leading parenthesis.
Let the server generate IDs
XADD with * takes the server's clock and guarantees the ID increases, including handling the case where the clock has not advanced since the last entry by bumping the sequence. A client-generated ID has to beat the current top or the write is rejected, and coordinating that across producers is not worth doing.
What this cannot see
It reads IDs and does not know your stream, so it cannot say whether an ID exists in it, whether it has been trimmed away by MAXLEN, or whether it is still pending for some consumer. The timestamp comes from whichever server generated it, so a clock skew between servers is invisible here.
Related redis tools
Redis RESP Protocol Decoder Read what the server actually sent Redis Connection URL Parser The path is the database number Redis CLUSTER NODES Parser Read the topology, and find the gap Redis Hash Slot Calculator Which of the 16,384 slots does this key land in? Redis Hash Tag Tester Will these keys survive a multi-key command? Redis RESP2 vs RESP3 Reply Decoder What the same reply looks like on each protocol
All 53 redis tools