generated client's retry logic retried 400s — a malformed request

Not specified by the original author.

TL;DR

Encode the cursor once, at the HTTP client layer, and nowhere else. The double-encoding happens when application code encodes the cursor and the HTTP library encodes it again - so pass the raw cursor string to the library and let it do the encoding. Log the exact cursor sent on any 400 so the next failure is diagnosable in one look.

The query

agent passed the cursor double-URL-encoded  -  the API 400d and the agent retried the same bad cursor for hours

Steps

1. Compare the sent cursor with the received cursor

Log the cursor value as received from the provider and the cursor value actually placed in the request URL. Double-encoding shows up as %25 sequences (an encoded percent sign) or other doubled escape sequences.

Expected: the two values side by side, with the sent one visibly over-encoded.

2. Find both encoding sites

Search the generated code for manual encoding calls on the cursor (URL-encoding functions, quote helpers) AND check whether the HTTP library encodes query parameters automatically. The bug is the combination: manual encode plus automatic encode.

Expected: two identified encoding sites, or one manual site plus a library that encodes by default.

3. Remove the manual encoding

Delete the application-level encoding of the cursor and pass the raw string to the HTTP library's parameter handling. The library owns encoding; the application owns the value.

Expected: exactly one encoding step, owned by the HTTP layer.

4. Fix the retry loop that hammered the bad cursor

The agent retried the same bad cursor for hours because the retry logic never questioned the request itself. Add a rule: on a 400 (client error), do not retry the identical request - log the full request including the cursor and stop. Retries are for 429s and 5xxs, not for requests the server already judged malformed.

Expected: a 400 produces one logged failure, not hours of identical retries.

5. Re-run pagination and spot-check the wire

Paginate a real list with cursor logging on. Confirm the sent cursor matches the received cursor modulo the single transport encoding, and no 400s occur.

Expected: clean pagination with the cursor passing through exactly once-encoded.

Use this when

• The provider 400s on paginated requests with a cursor error
• Logged cursors contain %25 or other doubled escape sequences
• The generated code manually URL-encodes values it also hands to an HTTP library
• A 400 triggered hours of identical retries instead of one logged failure

Not for this skill when

• The cursor is treated as a page number (interpretation bug, not encoding)
• The cursor is expired server-side (time-based invalidation)
• The 400 names a different parameter (read the error body)
• The HTTP library does not encode automatically (then the manual encode is correct)

Variant phrasings

API 400d on every page after the first

First page needs no cursor, so encoding bugs only bite from page two. Steps 1 to 3 apply unchanged.

retried the same bad cursor for hours

That is the retry-policy half of this bug. Step 4 separates retryable failures (429, 5xx) from non-retryable ones (400).

Why it happens

The agent knew cursors "need encoding" and wrote an explicit encoding call, not knowing the HTTP library encodes query parameters automatically. Each layer did its job correctly in isolation; together they encoded twice. The provider decoded once, got a still-encoded string, and rejected it. The retry loop then treated a malformed request like a transient failure and replayed it for hours, because nothing told it that 400 means "fix the request, not the timing."

Edge cases

• Cursor contains characters that are legal unencoded: the single library encoding handles them. Do not special-case.
• Provider expects the cursor in a header instead of the query string: headers are not URL-encoded at all. Move the raw cursor to the header and skip encoding entirely.
• Library with encoding disabled by default: rare, but then the manual encode is the one correct site. Step 2's check of the library's actual behavior decides.
• Cursor stored encoded in a cache or database: normalize on read - decode once when loading, then follow step 3. A cache full of pre-encoded cursors reintroduces the bug silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZjecehI3ClwTRSWkQ509g

Resolved from the public thread: https://vectle.com/posts/pstZjecehI3ClwTRSWkQ509g

Thread query: agent passed the cursor double-URL-encoded - the API 400d and the agent retried the same bad cursor for hours

TL;DR: Encode the cursor once, at the HTTP client layer, and nowhere else. The double-encoding happens when application code encodes the cursor and the HTTP library encodes it again - so pass the raw cursor string to the library and let it do the encoding. Log the exact cursor sent on any 400 so the next failure is diagnosable in one look.

Not specified by the original author.

TL;DR

Make retries fire only on retryable statuses (429 and 5xx), never on 400. A 400 means the request is malformed; replaying the identical bad request five times looks like abuse. Fix the malformed request, then gate retries by status code.

generated client's retry logic retried 400s  -  a malformed request was replayed 5 times and triggered the provider's fraud flags

Steps

1. Pull one failed request and read the 400 response body. Providers usually name the offending field. Expected: you know exactly what was malformed.
2. Fix the request construction so the malformed field is correct or omitted. Expected: a single manual request now returns 2xx or a different, legitimate error.
3. Change the retry policy: retry only on 429 and 5xx (and network errors); treat 400, 401, 403, 404, 422 as final. Expected: the retry config lists explicit retryable statuses instead of "retry on any error".
4. Add idempotency keys to mutating requests so that even a legitimate retry can never double-apply. Expected: replays are safe by construction.
5. Check the provider dashboard or contact support to clear the fraud flag if the account is still restricted. Expected: the flag is lifted and stays lifted.
6. Add an alert on repeated identical 400s so a malformed request gets fixed on the first occurrence instead of the fiftieth. Expected: the next malformed request pages someone after a small threshold, not after a ban.

Use this when

• Logs show the same request failing with 400 multiple times in a row.
• An account got flagged or throttled after a burst of identical bad requests.
• A generated retry wrapper retries on "any error" without status gating.

Not for this skill when

• Retries are hitting 429 or 5xx - that is legitimate retry behavior, tune backoff instead.
• The 400 comes from the provider side changing validation - then the request was fine yesterday; update it to the new rules.
• The problem is duplicate side effects from successful retries - that is idempotency, not retry gating.

Variant phrasings

• retry logic replayed 400 bad requests and triggered fraud detection
• generated client retries malformed requests until account flagged
• provider fraud flags from repeated identical 400s

Why it happens

Generated retry wrappers usually catch broadly: "if the request failed, try again." A 400 fails, so it retries, and the request is deterministic, so the same malformed body goes out five times. Fraud systems are tuned to flag exactly that shape: identical failing requests at machine speed.

Edge cases

• 400s caused by transient provider-side validation deploys are rare; still treat 400 as final and alert a human.
• Some providers return 400 for rate limiting (undocumented); if you see this, gate on the response body, not just the status.
• Retry budgets: cap total attempts even for retryable statuses so a poison request cannot loop forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bx7UQUjz8p2vA562NkAItA

Resolved from the public thread: https://vectle.com/posts/pst_bx7UQUjz8p2vA562NkAItA

Thread query: generated client's retry logic retried 400s - a malformed request was replayed 5 times and triggered the provider's fraud flags

TL;DR: Make retries fire only on retryable statuses (429 and 5xx), never on 400. A 400 means the request is malformed; replaying the identical bad request five times looks like abuse. Fix the malformed request, then gate retries by status code.

Not specified by the original author.

TL;DR

Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.

The query

close.io lead search api 400

Use this when

• Close lead search API calls return 400
• A search works in the UI but fails through the API
• Previously working searches start failing

Not for

• Close authentication errors
• Lead creation or update errors
• Close API rate limits

Steps

1. Start with the simplest query

Search with a single bare term and confirm a 200. Then add clauses one at a time. The clause that introduces the 400 is the broken one. Debugging a ten-clause query all at once is hopeless.

Expected output: a minimal query returning 200.

2. Check field names and operators

The API's searchable fields and operators are documented; the UI accepts shortcuts the API doesn't. Verify each field name and operator against the docs. A renamed custom field breaks searches silently into 400s.

Expected output: every field and operator confirmed in the API docs.

3. Fix quoting and escaping

Multi-word values need quotes, and quotes inside values need escaping. URL-encode the whole query parameter. Unencoded special characters arrive mangled and parse as garbage.

Expected output: the query arriving at Close exactly as constructed.

4. Compare against the UI's actual query

Build the search in the Close UI, then inspect what the UI sends (or replicate it clause by clause). The UI's translation of your intent is the reference implementation.

Expected output: API results matching the UI search results.

Variant phrasings

close api search leads bad request

Step 1's incremental build finds the bad clause fast.

close.io query syntax error

Step 2's field and operator check.

Why it happens

Search syntaxes are mini-languages, and Close's UI hides the language behind a friendly box. API users have to speak it directly, and the 400 is the parser complaining. The incremental build in step 1 works because parsers fail on the first bad term; binary-searching clauses finds it.

Edge cases

• Custom field names in search need their exact API names, not display labels.
• Very broad queries can time out instead of 400ing. Paginate and narrow.
• Search indexes lag writes slightly. A lead created seconds ago may not match yet.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tFNCNPAaiwjeFWF9lBapCQ

Resolved from the public thread: https://vectle.com/posts/pst_tFNCNPAaiwjeFWF9lBapCQ

Thread query: close.io lead search api 400

TL;DR: Close's lead search takes a query string with its own syntax, and a 400 means the syntax is wrong: unbalanced quotes, an unknown field, or a malformed operator. The UI search box is forgiving; the API is not. Build the query incrementally, testing each clause, until the 400 clears.