Hi, I'm running into an issue where making a request to the `team_log` endpoint succeeds if I specify a limit of 1 or 2 and no categories, but if I specify a limit of 3 or higher I get a 500. Successful request: ``` curl -vvv -X POST https://api.dropboxapi.com/2/team_log/get_events \ --header "Authorization: Bearer " \ --header "Content-Type: application/json" \ --data "{\"limit\": 1}" ``` Failing request: ``` curl -vvv -X POST https://api.dropboxapi.com/2/team_log/get_events \ --header "Authorization: Bearer " \ --header "Content-Type: application/json" \ --data "{\"limit\": 3}" ``` (a sample x-dropbox-request-id is 818508708152d804ef19f4dac7f6017a) Is this a known issue?

Child Item

Getting 500s from team_log API

Hi,

I'm running into an issue where making a request to the `team_log` endpoint succeeds if I specify a limit of 1 or 2 and no categories, but if I specify a limit of 3 or higher I get a 500.

Successful request:

```

curl -vvv -X POST https://api.dropboxapi.com/2/team_log/get_events \
--header "Authorization: Bearer <SNIPPED>" \
--header "Content-Type: application/json" \
--data "{\"limit\": 1}"

```

Failing request:

```

curl -vvv -X POST https://api.dropboxapi.com/2/team_log/get_events \
--header "Authorization: Bearer <SNIPPED>" \
--header "Content-Type: application/json" \
--data "{\"limit\": 3}"

```

(a sample x-dropbox-request-id is 818508708152d804ef19f4dac7f6017a)

Is this a known issue?

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

We've deployed a fix for an issue affecting /2/team_log/get_events that would have resulted in a 500 error like this.

Please try again now and let me know if you're still seeing any issues. If so, please provide some new request IDs for the latest failures. Thanks in advance!

All comments

Greg-DB

Thanks for the report! We're looking into it and I'll follow up here once I have an update for you.

Greg-DB

We've deployed a fix for an issue affecting /2/team_log/get_events that would have resulted in a 500 error like this.

Please try again now and let me know if you're still seeing any issues. If so, please provide some new request IDs for the latest failures. Thanks in advance!

logsnitch

Confirmed - thanks for the speedy fix!

Just to check, the right way to paginate all the log events would be:

1) make an initial request to get_events

2) continue polling to get_events/continue with the cursor from the previous get_events or get_events/continue call, until has_more = false. Once has_more = false, go back to step 1 with the max event timestamp I've seen so far (or should I keep polling the existing cursor and it will work if new events have come in?)

3) at any point in 2) I can get a bad_cursor or reset, in which case I should go back to step 1 with the max event timestamp I've seen so far (and add 1 second to not get duplicates?). Also the docs say in case of a reset the api response will include a timestamp to use - is there an example response showing that, or a way for me to induce that behavior myself? Since I have to keep track of the max event timestamp I've seen for the "bad_cursor" case anyway, maybe I should just always use that and ignore the value returned in the "reset" case?

Thanks again,

Greg-DB

Great, thanks for confirming that.

If you want to paginate through all events, you should page through using the cursors as you describe, except that you don't need to start over with the current timestamp once you get has_more = false. You should instead just use that latest cursor you received and call back to get_events/continue again later to check again.

And yes, if you then get a 'bad_cursor' or 'reset' error, you'll need to start over (optionally specifying a particular timestamp if you wish) to get a new cursor.

In the 'reset' case, the error will include a timestamp that you should use. Here's an example of what that would look like, for reference:

{
    "error_summary": "reset/...",
    "error": {
        ".tag": "reset",
        "reset": "2019-12-12T12:12:00Z"
    }
}