Seconds instead of milliseconds
An ID a thousand times too small, which sorts before every real entry
1700000000-0
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.
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.
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.
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.
An ID a thousand times too small, which sorts before every real entry
1700000000-0
Why passing 0 to XREADGROUP re-reads the pending list forever
1700000000000-0 $ > * -
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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 `*`.
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.
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.
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.
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.
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.
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.
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.
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.