kellcomnet | 2019-01-07 22:59:03 UTC | #1
When calling 'GET /platform/api/v2/billing/subscriptionoverview?periodEndingTimestamp=1546300799999' for any other billing period it returns valid results but this one bombs out.
HTTP/1.1 500 Internal Server Error Server: nginx Date: Mon, 07 Jan 2019 22:49:36 GMT Content-Type: application/json Content-Length: 174 Connection: keep-alive inin-ratelimit-count: 49 inin-ratelimit-allowed: 300 inin-ratelimit-reset: 48 ININ-Correlation-Id: 80325fb9-6f57-4e18-a8dc-95757b5a097a Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0
{"status":500,"code":"internal.server.error","message":"Unexpected token u in JSON at position 0","contextId":"80325fb9-6f57-4e18-a8dc-95757b5a097a","details":[],"errors":[]}
working example GET /platform/api/v2/billing/subscriptionoverview?periodEndingTimestamp=1548979199999 HTTP/1.1
HTTP/1.1 200 OK Server: nginx Date: Mon, 07 Jan 2019 22:49:36 GMT Content-Type: application/json Connection: keep-alive ININ-Correlation-Id: e65ea0b5-dcce-4514-98c7-e808cd8e3b84 inin-ratelimit-count: 48 inin-ratelimit-allowed: 300 inin-ratelimit-reset: 48 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 Content-Length: 1275
{"currency":"USD","enabledProducts":["PureCloudCommunicateMonthlyUsage","PureCloudCollaborateMonthlyUsage","PureCloudCommunicateStandaloneMonthlyUsage","PURECLOUDMINREQUIREMENT","PureCloud2ConcurrentMonthlyUsage","PureCloudEdgeVirtual"],"subscriptionType":"MONTHTOMONTH","usages":[{"name":"PureCloud Collaborate User","grouping":"user-license","unitOfMeasureType":"seat","usageQuantity":"0","overagePrice":"0.00"},{"name":"PureCloud Communicate Stand-alone Phone","grouping":"device","unitOfMeasureType":"phone","usageQuantity":"0","overagePrice":"11.99"},{"name":"PureCloud Communicate User","grouping":"user-license","unitOfMeasureType":"seat","usageQuantity":"0","overagePrice":"18.00"},{"name":"PureCloud 2 Concurrent User","grouping":"user-license","unitOfMeasureType":"seat","usageQuantity":"222","overagePrice":"175.00"},{"name":"PureCloud Min Requirement","grouping":"user-license","unitOfMeasureType":"seat","usageQuantity":"0","overagePrice":"1.00"},{"name":"PureCloud Edge Virtual","grouping":"device","unitOfMeasureType":"device","usageQuantity":"0","overagePrice":"99.99"}],"isInRampPeriod":false,"rampPeriodStartingTimestamp":"2017-12-01T08:00:00.000Z","rampPeriodEndingTimestamp":"2017-12-01T08:00:00.000Z","selfUri":"/api/v2/billing/subscriptionoverview"}
tim.smith | 2019-01-08 14:56:36 UTC | #2
All 5xx errors need to be reported to PureCloud Care for investigation.
SPMCSteve | 2019-01-09 19:15:38 UTC | #3
Tim:
Was looking through this post; I get about 10-20 5xx (500 and 504 usually) errors a day, with code that when it runs again a few seconds later doesn't error at all (and no changes are made).
Is there a better way than opening a ticket every time it happens? It is a pretty regular occurrence so frankly I have been ignoring them as the code is robust enough to go and back fill whatever was missed the last time it errored.
tim.smith | 2019-01-09 19:26:10 UTC | #4
If there's a consistent action or pattern that causes a 5xx error, absolutely report those since there's a pattern of failure. If it's an occasional error that you can just retry once and it works, it's up to you if you'd like for the Care team to investigate the cause or not. The reality of a multi-tennant cloud service handling literally billions of API requests monthly is that there will be a few mishandled requests from time to time due to scale up/down timing or other benign causes that aren't indicative of a chronic problem. Regardless, we take all of those problem reports seriously and will learn everything we can from each report to improve the PureCloud services.
SPMCSteve | 2019-01-09 19:28:06 UTC | #5
I will try and add some logging the next time I am in the code, so the failures are logged in a meaningful way that I can pass along in a batch then. Probably the easiest for your team to deal with them that way. As I say it is regular, some days more than others, but pretty much every day I have at LEAST one failure, most days are in the low double digits.
kellcomnet | 2019-01-09 19:39:32 UTC | #6
@tim.smith Correct me if I am wrong, but the correlation id is required for troubleshooting correct? So that should always be included in cases related to API failures?
tim.smith | 2019-01-09 19:44:52 UTC | #7
Correct. Correlation ID is a must have, also providing the request and response body is nice to have since we don't necessarily log the exact request and response body.
kellcomnet | 2019-01-13 04:35:59 UTC | #8
fyi on my customer care case, the tech indicated this is a known bug.
system | 2019-02-13 04:36:02 UTC | #9
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
This post was migrated from the old Developer Forum.
ref: 4303