dashboard.wireless.getOrganizationWirelessDevicesEthernetStatuses total_pages='all' PAGNATION_ISSUE

[mforman]

Greetings!

Initially I tried to perform this using the python request module and experienced an issue while trying to work through the response.links (for next page) so I spun up a python venv to test this on the python meraki sdk and experienced similar results.

Sample Code:

import meraki
dashboard = meraki.DashboardAPI(YOUR_merakiApiKey)
response = dashboard.wireless.getOrganizationWirelessDevicesEthernetStatuses(YOUR_merakiOrgID, total_pages='all')
print(response)

It just continues to run but the url for the next page never changes.

aka: "startingAfter"

terminal logs:

2023-03-21 16:26:46 meraki: INFO > GET https://api.meraki.com/api/v1/organizations/XX/wireless/devices/ethernet/statuses
2023-03-21 16:26:46 meraki: INFO > wireless, getOrganizationWirelessDevicesEthernetStatuses; page 1 - 200 OK
2023-03-21 16:26:46 meraki: INFO > GET https://n545.meraki.com/api/v1/organizations/XX/wireless/devices/ethernet/statuses?perPage=100&start...13803415844340
2023-03-21 16:26:47 meraki: INFO > wireless, getOrganizationWirelessDevicesEthernetStatuses; page 2 - 200 OK
2023-03-21 16:26:47 meraki: INFO > GET https://n545.meraki.com/api/v1/organizations/XX/wireless/devices/ethernet/statuses?perPage=100&start...13803415844340
2023-03-21 16:26:47 meraki: INFO > wireless, getOrganizationWirelessDevicesEthernetStatuses; page 3 - 200 OK

[sungod]

Is the problem that the

dashboard.wireless.getOrganizationWirelessDevicesEthernetStatuses 

library call just runs 'forever'? If so, it sounds a bit like a problem I found with the events call...

https://community.meraki.com/t5/Developers-APIs/Events-same-event-different-API-return-also-call-nev...

I eventually put some debug print to stderr in the rest_session.py library file, that let me figure out the causes and  a fix.

Combination of things: the actual API endpoint wasn't quite following the documented pagination rules, but also the Meraki Python library had some loop breaking logic that didn't work in this situation.

At the moment there is a support case open on the endpoint, I also reported on Github but so far the library has not been fixed, I just add my own patch to handle the problem.

It is not quite the same as the problem you have but my guess is it's similar.