Route analytics endpoints to their correct hosts - #6
Merged
Conversation
Detailed Call History (cdr_feed/cdr_stream) and the Admin analytics
reports are served from analytics hosts, not webexapis.com, so both
were 404ing. The Postman collections use {{baseUrl}} for every request,
so the real host is not in the source data — record it in a
BASE_URL_OVERRIDES table in generate_cli.py keyed by collection and
path prefix, applied per endpoint during codegen.
CDR hosts are region-specific, so add a --region flag (us, ca, eu, eun,
in, au) resolved from --region > WEBEX_REGION > config file, plus a
"webex config set region" key. An HTTP 451 now returns an actionable
error naming the endpoint Webex pointed us at.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
webex calling reports-detailed-call-history get404s: it was hittingwebexapis.com/v1/cdr_feedinstead ofanalytics-calling.webexapis.com/v1/cdr_feed.The Postman collections use
{{baseUrl}}for every request, so the real host neverreaches
api_spec.jsonand the generator stamped the collection default onto everyendpoint.
Same bug in
admin analytics, which builtwebexapis.com/v1/v1/analytics/...— thosepaths already carry
/v1and belong toanalytics.webexapis.com.Fix
codegen/generate_cli.py:BASE_URL_OVERRIDES(collection → path prefix → Go baseURL expression), resolved per endpoint by longest matching prefix. New endpoints
under those prefixes are covered automatically on the next
make codegen.internal/config:AnalyticsBaseURLplusAnalyticsCallingBaseURL(), which mapsthe data region to the documented FQDN (us/ca, eu/eun, in, au), defaulting to US.
--regionglobal flag, resolved--region>WEBEX_REGION> config file, withwebex config set region <r>; invalid values are rejected up front.endpoint from the response body and the flag to set.
cmd/calling/reports_detailed_call_history.goandcmd/admin/analytics.go.Verified against the live API
reports-detailed-call-history get→analytics-calling.webexapis.com/v1/cdr_feed, HTTP 200 with real CDRs.--region eu→ EU host, 451 →wrong data region (451): ... Webex says to use https://analytics-calling.webexapis.com — rerun with --region <us|ca|eu|eun|in|au>.--region xx→ rejected with the valid list.admin analytics historical-data-related-messaging→ correct host; returns a real 403 (no propack subscription) instead of a 404.Known gap (not addressed)
--paginateon the CDR commands still uses the Callingstart/maxstrategy, but CDRpaginates via the
Linkheader withstartTimeForNextFetch.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.