[ContentUnderstanding][P1] Python SDK default polling_interval (30s) is too high
Language: Python
Notebook scenario: All scenarios using begin_analyze / begin_analyze_binary
Repro Steps
- Create a
ContentUnderstandingClient with all defaults (no polling_interval override)
- Call
begin_analyze_binary() with a small PDF (e.g., sample_invoice.pdf, ~100KB)
- Measure E2E time from
begin_analyze_binary() to .result()
Expected Result
E2E time should be ~7-15s, matching actual server processing time.
Actual Result
E2E time is ~33s due to default polling_interval=30 in ContentUnderstandingClientConfiguration.
The first GET poll doesn't happen until 30s after the POST, even though the operation typically completes in ~7-15s. This means the client sits idle for ~15-25s before discovering the result is ready.
Evidence from testing:
polling_interval=1: E2E = ~7s (POST ~2.5s + 3-4 GET polls at ~1s intervals)
polling_interval=30 (default): E2E = ~33s (POST ~2.5s + 30s wait + 1 GET poll)
Root Cause
ContentUnderstandingClientConfiguration sets self.polling_interval = kwargs.get("polling_interval", 30). This 30s default is too conservative for Content Understanding operations.
Suggestion
Consider lowering the default to 1-5 seconds, or implement exponential backoff starting from a short interval (e.g., 1s → 2s → 4s → 8s → ...).
The service does not return a Retry-After header, so the SDK purely relies on polling_interval.
[ContentUnderstanding][P1] Python SDK default polling_interval (30s) is too high
Language: Python
Notebook scenario: All scenarios using begin_analyze / begin_analyze_binary
Repro Steps
ContentUnderstandingClientwith all defaults (nopolling_intervaloverride)begin_analyze_binary()with a small PDF (e.g., sample_invoice.pdf, ~100KB)begin_analyze_binary()to.result()Expected Result
E2E time should be ~7-15s, matching actual server processing time.
Actual Result
E2E time is ~33s due to default
polling_interval=30inContentUnderstandingClientConfiguration.The first GET poll doesn't happen until 30s after the POST, even though the operation typically completes in ~7-15s. This means the client sits idle for ~15-25s before discovering the result is ready.
Evidence from testing:
polling_interval=1: E2E = ~7s (POST ~2.5s + 3-4 GET polls at ~1s intervals)polling_interval=30(default): E2E = ~33s (POST ~2.5s + 30s wait + 1 GET poll)Root Cause
ContentUnderstandingClientConfigurationsetsself.polling_interval = kwargs.get("polling_interval", 30). This 30s default is too conservative for Content Understanding operations.Suggestion
Consider lowering the default to 1-5 seconds, or implement exponential backoff starting from a short interval (e.g., 1s → 2s → 4s → 8s → ...).
The service does not return a
Retry-Afterheader, so the SDK purely relies onpolling_interval.