{"limit":{"track":x}} value unordered - negative deltas


Hi, we’ve recently noticed that the values returned by the Streaming API when we’re being rate limited have become unordered.

Historically the value x in {“limit”:{“track”:x}} was always increased in value from one payload to the next. Now it seems the values are unordered, resulting in negative deltas between pairs of payloads.

Is this a deliberate change in the way the track messages are designed to work? A side effect of another change, which is expected to remain this way? Or an unintentional bug which we can expect to go away at some point?

Alex Kelly

Why are track values in LIMIT notices out of order and how to interpret them?
Non-monotonic Rate Limit Message Counts

Related to: https://dev.twitter.com/discussions/32557


I’ve noticed this too. The current documentation indicates that the number is supposed to be cumulative for the connection? Should we just assume that the highest value received is correct?