fix(gooddata-eval): wait out the Langfuse rate-limit window on a 429

Langfuse Cloud rate-limits public API calls per organization in fixed
one-minute windows, and score writes share the bucket with observation
and score reads (30/min on Hobby, 1,000/min on Pro). A 429 carries a
Retry-After counting down to the window's reset, often 30-60 s.

create_score capped every retry wait at 5 s, so both retries landed in
the same exhausted window and the score was dropped. On a Hobby project
a 60-request burst lost 43 scores this way. A 429 now waits up to the
60 s window; 5xx retries keep the 5 s cap.

jira: trivial
risk: low

Author: tychtjan

packages/gooddata-eval/src/gooddata_eval/core/langfuse/client.py

@@ -29,6 +29,9 @@
 _MAX_SCORE_ATTEMPTS = 3
 _DEFAULT_RETRY_DELAY = 0.5
 _MAX_RETRY_DELAY = 5.0
+# Langfuse Cloud rate-limits in fixed one-minute windows, and a 429's Retry-After counts down to
+# the window's reset. A shorter wait retries into the same exhausted window and loses the score.
+_MAX_THROTTLE_DELAY = 60.0
 
 
 def _is_retryable(resp: httpx.Response) -> bool:
@@ -38,16 +41,16 @@ def _is_retryable(resp: httpx.Response) -> bool:
 def _retry_delay(resp: httpx.Response) -> float:
     """Seconds to wait before the next attempt, from `Retry-After` when the server names one.
 
-    Unparsable, negative or NaN values fall back to the default; the cap bounds the wait so a
-    throttled score cannot hold a linking worker for long.
+    Unparsable, negative or NaN values fall back to the default. A 429 waits up to one rate-limit
+    window; any other retryable status is capped at a few seconds.
     """
     try:
         asked_for = float(resp.headers.get("Retry-After", ""))
     except ValueError:
         return _DEFAULT_RETRY_DELAY
     if not asked_for >= 0:
         return _DEFAULT_RETRY_DELAY
-    return min(asked_for, _MAX_RETRY_DELAY)
+    return min(asked_for, _MAX_THROTTLE_DELAY if resp.status_code == 429 else _MAX_RETRY_DELAY)
 
 
 class _TraceListResult:

packages/gooddata-eval/tests/test_langfuse_client.py

@@ -151,14 +151,22 @@ def test_a_retry_after_that_cannot_be_slept_falls_back_to_the_default(header):
     assert client_module._retry_delay(httpx.Response(429, headers={"Retry-After": header})) == 0.5
 
 
-def test_a_retry_after_beyond_the_cap_is_clamped():
-    assert client_module._retry_delay(httpx.Response(429, headers={"Retry-After": "60"})) == 5.0
+def test_a_throttled_score_waits_out_the_whole_rate_limit_window():
+    # Langfuse limits in fixed one-minute windows and names the wait until the window resets.
+    assert client_module._retry_delay(httpx.Response(429, headers={"Retry-After": "56"})) == 56.0
+
+
+def test_a_retry_after_beyond_one_window_is_clamped_to_one_window():
+    assert client_module._retry_delay(httpx.Response(429, headers={"Retry-After": "600"})) == 60.0
+
+
+def test_a_server_error_retry_after_stays_short():
+    assert client_module._retry_delay(httpx.Response(503, headers={"Retry-After": "60"})) == 5.0
 
 
 def test_a_retry_after_given_as_a_date_falls_back_to_the_default():
-    # Retry-After is allowed to be an HTTP-date; this client reads seconds only. Langfuse
-    # documents the header as a number of seconds, and the cap already bounds the wait, so
-    # parsing a date could only turn the 0.5s fallback into the same 5s ceiling.
+    # Retry-After is allowed to be an HTTP-date; this client reads seconds only, which is the
+    # form Langfuse documents and sends.
     response = httpx.Response(429, headers={"Retry-After": "Wed, 21 Oct 2026 07:28:00 GMT"})
     assert client_module._retry_delay(response) == 0.5