stream_position badly lagging?




  • 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.

    コメントアクション 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.



    コメントアクション 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?

    コメントアクション Permalink