corrupt cursor in contacts list

[alexkunger]

We were not able to use the python sdk to pull the full contact list. It would error in a bad iterator on the second page of results from the rest api.
We resolved the issue by adding a limit param to the list call and then running the request once and then removing the limit param and the full request succeeded.
It seem the cursor on your server was somehow corrupt and then when a new one was issued it resolved itself.
The error was persistent over multiple days until we added that limit param.

[dp-rufus]

Thanks for the info and sorry you had problems. I will pass this on to the relevant team members for investigation

[alexkunger]

@dp-rufus has this been investigated? it is now happening even more frequently

[dp-rufus]

Hi Alex
To help me find this in our logs and figure the problem out, please can you confirm my understanding:

When this problem occurs (intermittent but increasingly frequent),

• A request GET /api/v2/contacts (page 1) will appear to complete successfully
  • http 200 status code
  • 'items' array of contacts
  • plausible-looking 'cursor' value (a long string, not absent or null)
  • are you providing the optional owner_id parameter?
• You then (quickly afterwards) request GET /api/v2/contacts?cursor=xxxxx for page 2
  • this request fails - in what manner?
  • what status code do you get?
  • do you get any error message in the json response?
• By repeating request 1 with a limit value, you could 'trick' the API into returning a different cursor, and this cursor then worked successfully in request 2
  • what limit value are you using?

Thanks for your help

[alexkunger]

We are using the python sdk python-dialpad==2.1.0. We call contacts = dp_client.contact.list(owner_id=x)

We get the following error:
500 Server Error: Internal Server Error for url: https://dialpad.com/api/v2/contacts?limit=25&owner_id=4526224355819520'

Stack trace:
"/usr/local/lib/python3.9/site-packages/dialpad/resources/contact.py line 20 in list", "/usr/local/lib/python3.9/site-packages/dialpad/resources/resource.py line 11 in request", "/usr/local/lib/python3.9/site-packages/dialpad/client.py line 74 in request", "/usr/local/lib/python3.9/site-packages/requests/models.py line 953 in raise_for_status"

We started with limit 25 but then that stopped working so we went to random between 20 and 30. That now no longer works. I think the cursors are getting corrupted somehow and then not being removed.

[dp-rufus]

Thanks for the info, I've found your stacktraces on our side. Please bear with me while I figure out the root cause and how to address it (I don't think it's related to cursors, surprisingly)

[alexkunger]

Great. Thank you. Looking forward to seeing the solution.

[dp-rufus]

We're tracking the issue internally as DP-45739

In the meantime please consider adding retry logic on your side.

If you subclass DialpadClient you can attach a custom urllib3 Retry policy with an adaptor:

from urllib3.util import Retry
from requests.adapters import HTTPAdapter

retry_policy = Retry(.............................)
retry_adapter = HTTPAdapter(max_retries=retry_policy)

class BetterDialpadClient(DialpadClient):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._session.mount("https://", retry_adapter)

[alexkunger]

I'll give that a try and let you know if the issue continues. Thank you for creating the internal issue and tracking for us. Much appreciated.

…

-Alex

On Mon, Jan 31, 2022 at 8:48 PM dp-rufus ***@***.***> wrote: We're tracking the issue internally as DP-45739 In the meantime please consider adding retry logic on your side. If you subclass DialpadClient you can attach a custom urllib3 Retry policy with an adaptor: from urllib3.util import Retryfrom requests.adapters import HTTPAdapter retry_policy = Retry(.............................)retry_adapter = HTTPAdapter(max_retries=retry_policy) class BetterDialpadClient(DialpadClient): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self._session.mount("https://", retry_adapter) — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOP6VYHTGJT4JWRCKXK47LUY5QZ7ANCNFSM5KESZWOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alexkunger]

How is work on the fix going?

[alexkunger]

any updates here?

[tinvaan]

Hey @alexkunger, looks like @dp-rufus is no longer active here. @bendialpad, is this something you can triage with your team?