Skip to main content
Question

stream_position badly lagging?

  • May 21, 2025
  • 3 replies
  • 20 views
C
Forum|alt.badge.img

It's entirely possible this is just a Monday thing and my brain isn't quite working full-speed yet, but has anyone else noticed this stream position behavior?

 

Here are my steps:

 

1) First, I just did a GET to https://api.box.com/2.0/events

 

2) As expected, since I did not specify a stream_position, this returns a chunk of 100 very old events

 

3) Next, I grabbed the next_stream_position off the bottom of the result from step 1 and plugged it into my URL, like this:  https://api.box.com/2.0/events?stream_position=creditcard

 

4) Hmm...still returns a chunk of 100 very old events

 

5) Try step 3 multiple new times (grabbing the next_stream_position each time) and always get the same result specified in step 4

 

6) Finally, tried to do a GET to https://api.box.com/2.0/events?stream_position=now

 

7) Results are much better - it's an empty collection of events

 

😎 Using the next_stream_position from step 6, do a GET like https://api.box.com/2.0/events?stream_position=creditcard

 

9) This also works great (returns an empty collection of events)

 

Take note of the diff between the next_stream_position returned via a "regular" GET of events (step 3: creditcard) and the next_stream_position returned via a "stream_position=now" GET of events (step 8: creditcard).  This is a difference of 3,024,818,207.

 

Now, I know the stream_position moves ahead rapidly, but not THAT rapidly!

 

Has anyone else noticed this behavior, or is there something specifically borked in our account?  My instinct is this is an issue that would effect all Box users, as it is my understanding the stream_position is universal system-wide.

 

    3 replies

    C
    Forum|alt.badge.img

     This is the expected behavior of the events endpoint. These are great observations, so I'll do my best to clarify the role of stream_position.

     

    You can think of stream_position as a cursor in our events database. It does not represent the number of events in your Box instance, but rather serves as a pointer to a specific event within a list of all your events ordered by date. 

     

    Another important thing to note is the value of stream_position returned in subsequent API calls will increase but not necessarily be consecutive. This is why you saw the the large increases in stream_position values between calls.

    C
    Forum|alt.badge.img

    Hey ,

     

    Thanks for the response, but I don't think you are quite following my question/concern.  We've heavily leveraged the "stream_position" concept in the code we've written against the Box API and it's worked great for us, so I understand the concept very well.

     

    To make my question more specifc:  if I were to do these two GETs at the exact same instant -

     

    https://api.box.com/2.0/events

    https://api.box.com/2.0/events?stream_position=now

     

    Given that those 2 GETs were made at the exact same instant in time, would you expect that the "next_stream_position" returned in the respective responses would be the same?

     

    Based on my understanding of the "next_stream_position" (as well as my experience working with the Box event API), I would expect these 2 numbers to be the same.  But instead what I'm seeing is the "next_stream_position" being returned by the "https://api.box.com/2.0/events" is falling further and further behind the "next_stream_position" being returned by the "https://api.box.com/2.0/events?stream_position=now" call (it was off by around ~3,100,000,000 when I first posted yesterday; this morning it's off by around 3,705,028,883)

     

    In fact, the "next_stream_position" being returned by the GET to "https://api.box.com/2.0/events" is not moving forward at all.  I can make that same GET repeatedly over a period of time and it never moves forward.

     

     

    C
    Forum|alt.badge.img

    Hmm, perhaps I don't understand this as well as I claim to!  🙂

     

    I was reading some of the fine print in the API docs and it seems to defy my (apparently faulty) understanding of how the next_stream_position works - specifically (bolding my own for emphasis):

     

    If you send stream_position=now then Box returns an empty list and the parameter stream_position with the latest stream position as its value. Using stream_position=now works only when the stream_type is not admin_logs.

     

    If you send no stream_position parameter then Box send all available events, beginning with the oldest stream position.

     

    Very interesting - I think I would amend my question to be "how does Box determine 'the oldest stream position'?"  Presumably by keeping track of the last stream position that I've checked?

    Terms of ServiceAccessibility statement