DEV Community: Vectle

Groq 429s: your retry loop is blind, read the headers instead

Rachel Vectle — Fri, 09 Oct 2026 17:41:29 +0000

Getting 429s from Groq and just sleeping a few seconds before retrying? That works until it doesn't.

import time, requests

resp = requests.post("https://api.groq.com/openai/v1/chat/completions",
                     headers={"Authorization": f"Bearer {KEY}"},
                     json=payload)
if resp.status_code == 429:
    time.sleep(5)  # blind retry. this is the bug.
    resp = requests.post(url, headers=headers, json=payload)

Here is what the Groq docs say that most retry loops ignore: every response carries x-ratelimit-* headers, and retry-after appears ONLY on 429 responses. The wait time you are guessing at is sitting right there in the 429 response, and the loop above threw it away.

The headers that matter:

x-ratelimit-limit-requests: your RPD (requests per day) cap
x-ratelimit-limit-tokens: TPM cap
x-ratelimit-remaining-requests / -remaining-tokens: how much headroom is left
x-ratelimit-reset-requests / -reset-tokens: when the window resets
retry-after: set only on 429s. the authoritative wait time. use it.

The dead ends we keep seeing in real agent runs:

Fixed sleep hammering an org-level limit. Groq enforces limits at the org level, not per user. One noisy retry loop can starve the whole org while it burns through attempts.
Watching TPM while OTPM trips you. Some accounts get an input/output token split (ITPM/OTPM). A huge output can trip OTPM even when total TPM looks fine, and your loop sees "tokens are fine" and retries straight into the same wall.
Cached tokens don't count toward limits. A high cache hit rate lowers effective pressure, which is great for throughput but confusing when the usage numbers don't add up.

What actually works: read retry-after from the 429 and back off to exactly that window. Check your real numbers at console.groq.com/settings/limits instead of guessing.

Full notes on the gotchas, including the ITPM/OTPM split and the org-level trap:
https://vectle.com/skills/skl_2mbinMsdstsavd9J2DD2jA

index_id is only valid for api_version='v1': the LlamaIndex Vertex AI v2 migration trap

Rachel Vectle — Thu, 08 Oct 2026 17:06:11 +0000

Upgraded your LlamaIndex Vertex AI vector store, flipped api_version='v2', and got this?

from llama_index.vector_stores.vertexaivectorsearch import (
    VertexAIVectorStore,
)

store = VertexAIVectorStore(
    project_id="my-project",
    region="us-central1",
    index_id="my-index-id",  # leftover from your v1 config
    api_version="v2",
)
# index_id is only valid for api_version='v1'

Heres the thing the release notes dont spell out clearly: v1 and v2 are not the same API with a version flag. v2 replaces the index-plus-endpoint model with collections. Passing v1 params next to api_version='v2' just dies. Mixing the two param styles is the most common way agents blow up a migration, because the old code "looks" almost right.

The dead ends we kept seeing:

Assuming v2 accepts index_id/index_endpoint_id the way v1 did. It doesnt. Those params belong to api_version='v1' only.
Calling v2 operations without the right package. v2 ops need google-cloud-vectorsearch installed. pip install the [v2] extra or things fail before you get anywhere.
Trying store.clear() on v1. v1 doesnt support clear() at all, so if your cleanup code has been calling it, it has silently never worked.

What actually works: drop index_id, use collections with v2, install the v2 extra. And heres the migration bonus, clear() is supported on v2, so moving over is also the only way to get deletes working.

Not ready to migrate? Set VERTEX_AI_ENABLE_V2 to false and you get the old v1 behavior back while you sort out the collections move.

Full notes on the migration gotchas, including the package and env-var details:
https://vectle.com/skills/skl_2Jr-p1oGDU48kT03YyIUmA

Eppo PHP SDK works on your laptop, then dies on a read-only filesystem

Rachel Vectle — Mon, 05 Oct 2026 17:14:23 +0000

You deploy to your usual staging box and the feature flags work. You push the same code to Lambda, or a container with a read-only root filesystem, and the app dies on boot with a cache write failure.

Here is the line from the Eppo PHP quickstart that does it:

use Eppo\EppoClient;

$eppoClient = EppoClient::init(
    '<your_api_key>',   // SDK key, first arg
    '<base_url>',       // optional, defaults to the Eppo CDN
    $assignmentLogger,  // optional
    $cache,             // optional PSR-16 cache. skip it and FileSystem cache is used
    $httpClient,        // optional PSR-18, else auto-discovered
    $requestFactory,    // optional PSR-17, else auto-discovered
);

See $cache. Optional means nobody passes it. The default is a FileSystem cache, which is fine everywhere you tested and fatal on any box where the process cannot write. The error surfaces on boot, before any flag config matters, so the first dead end people chase is the SDK key or the network. It is neither.

The fix is to stop treating those init args as optional in production:

use Eppo\EppoClient;
use Symfony\Component\Cache\Adapter\RedisAdapter;
use Symfony\Component\Cache\Psr16Cache;

$redisCache = new Psr16Cache(RedisAdapter::createConnection('redis://localhost'));

$eppoClient = EppoClient::init(
    $_ENV['EPPO_SDK_KEY'], // SDK key first
    null,                 // leave the base URL unset unless you run a custom endpoint
    null,                 // assignment logger, if you have one
    $redisCache,          // explicit PSR-16 cache, Redis or Memcached in prod
    $httpClient,          // your own PSR-18 client, not discovery's guess
    $requestFactory,      // your own PSR-17 factory
);

That last point is the quiet part of the same bug: letting HTTP client discovery pick whatever is installed is fine locally and a lottery in production. Pin it.

The agent-readable version of this, fetchable via curl, lives on Vectle:

https://vectle.com/skills/skl_1TDVbXyxhKSxkxHObep0VQ

(Source: Eppo PHP quickstart, docs.geteppo.com/sdks/server-sdks/php/quickstart)

Your Oxylabs SOCKS5 geo targeting is doing nothing

Rachel Vectle — Sun, 04 Oct 2026 16:58:07 +0000

If you are routing traffic through Oxylabs and set geo targeting in the username, it works right up until you switch protocols. Then it quietly stops doing anything.

# HTTPS: this works. country entry node, port 10000
curl -x https://customer-USERNAME:pass@us-pr.oxylabs.io:10000 https://ip.oxylabs.io/location

# SOCKS5: this entry node has no geo routing at all
curl -x socks5://customer-USERNAME:pass@us-pr.oxylabs.io:10000 ...

That is the catch. Oxylabs country entry nodes only exist for HTTPS-style proxying. There is no SOCKS5 equivalent. If your tooling or agent flips to SOCKS5 (plenty of them default to it), your cc-DE username param is what actually carries the geo, not the entry node. Ignore this and you end up with traffic entering through whatever country the generic node picks.

The working combos:

HTTPS / HTTP: us-pr.oxylabs.io:10000 (US), eu-pr.oxylabs.io:10000 (EU), port 10001 for sticky country entry
SOCKS5: forget entry nodes, use customer-USERNAME-cc-XX in the username, where XX is your country code
pr.oxylabs.io:7777: the generic entry point. Fine as a default, but it does not pin the entry country the way a country entry node does

One more from the same docs page, for anyone wiring proxies into Proxifier: Oxylabs Mobile Proxies are not supported there. Use residential.

The agent-readable version of this (fetchable via curl) lives on Vectle:

https://vectle.com/skills/skl_1Say5TmErDKnkz7162Sf5w

(Source: Oxylabs Proxifier integration guide, https://oxylabs.io/resources/integrations/proxifier)