Summary
The 429 retry handlers in admin_graphql_request coerce Retry-After with int(), which raises ValueError on any value that is not a bare integer. HTTP permits a decimal seconds value as well as an HTTP-date, and decimal values are what Shopify's own rate-limited REST responses carry.
The exception is uncaught, so it propagates out of admin_graphql_request instead of being retried or returned as a GQLResult.
Version: shopifyapp 1.0.1 (sdist from PyPI).
Cause
shopify_app/graphql/admin_graphql.py:398 (sync):
time.sleep(int(retry_after))
and shopify_app/graphql/admin_graphql.py:454 (async):
await asyncio.sleep(int(retry_after))
Reproduction
>>> int("2.0")
Traceback (most recent call last):
...
ValueError: invalid literal for int() with base 10: '2.0'
Currently masked
This is not reachable today, because the header is never actually read: response_headers.get("Retry-After", "1") always returns its "1" default, for the reason described in #17.
That coupling is the reason this is worth filing on its own — repairing the header lookup alone turns a silent bug into an uncaught exception. The two are best addressed together.
Suggested fix
Parse defensively and fall back rather than raising:
try:
delay = float(retry_after)
except (TypeError, ValueError):
delay = 1.0
time.sleep(delay)
float() accepts the integer form as well, so it covers both spellings. If HTTP-date support is wanted, email.utils.parsedate_to_datetime handles that form.
Summary
The 429 retry handlers in
admin_graphql_requestcoerceRetry-Afterwithint(), which raisesValueErroron any value that is not a bare integer. HTTP permits a decimal seconds value as well as anHTTP-date, and decimal values are what Shopify's own rate-limited REST responses carry.The exception is uncaught, so it propagates out of
admin_graphql_requestinstead of being retried or returned as aGQLResult.Version:
shopifyapp1.0.1 (sdist from PyPI).Cause
shopify_app/graphql/admin_graphql.py:398(sync):and
shopify_app/graphql/admin_graphql.py:454(async):Reproduction
Currently masked
This is not reachable today, because the header is never actually read:
response_headers.get("Retry-After", "1")always returns its"1"default, for the reason described in #17.That coupling is the reason this is worth filing on its own — repairing the header lookup alone turns a silent bug into an uncaught exception. The two are best addressed together.
Suggested fix
Parse defensively and fall back rather than raising:
float()accepts the integer form as well, so it covers both spellings. IfHTTP-datesupport is wanted,email.utils.parsedate_to_datetimehandles that form.