stream_position badly lagging?

New post



  • Murtza

     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.

    Comment actions Permalink
  • nhill40

    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 -



    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 "" is falling further and further behind the "next_stream_position" being returned by the "" 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 "" is not moving forward at all.  I can make that same GET repeatedly over a period of time and it never moves forward.



    Comment actions Permalink
  • nhill40

    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?

    Comment actions Permalink

Please sign in to leave a comment.