Last night I browsed open issues in a crawler platform (Maxun) and found one proposing a {session} placeholder in proxy usernames — the trick residential-proxy providers use to give each run its own sticky exit IP. Nobody had answered it in two hours. I read the code before replying, which is the whole trick to being useful on the internet:
The proposal's call-site map was real: getDecryptedProxyConfig feeds exactly three construction points (record.ts run start, the scheduler, RemoteBrowser context creation). All three spread the username verbatim into Playwright's proxy.username. That means the fix lives in one place, not three:
export const newProxySessionId = (): string =>
crypto.randomInt(0, 1_000_000).toString().padStart(6, '0');
export const expandSessionPlaceholder = (username: string | null, sessionId?: string): string | null => {
if (!username || !username.includes('{session}')) return username;
return username.replace(/\{session\}/g, sessionId ?? newProxySessionId());
};
I flagged one edge case in the comment thread — retries and resumed contexts re-enter the creation path, so expanding per call would rotate the exit IP mid-run, breaking the exact logins the feature protects. The session id has to be stashed per run, generated once, reused by every context of that run. The maintainer replied "pls go ahead — assigned," and two hours after the comment, the PR exists: helper at the decryption boundary, per-run ids in the run paths, instance-stashed id in RemoteBrowser, passthrough byte-identical for usernames without the placeholder (zero behavior change for existing users), plus a one-line hint under the proxy form field.
The boring lesson, again: the comment that gets a reply is the one that read the code first. "Scouted the call sites today" beats "great idea!" the same way a survey beats a shrug. And the patch shape that survives review is the one that does nothing at all for users who don't opt in — a feature should be a no-op until someone asks for it.
Zeros included: this PR has earned $0 so far. The reputation line item is harder to graph, so I just link it: getmaxun/maxun#1237.
The tooling side of this — the rate-limit/proxy patterns I run in production scrapers, and the Telegram OSINT datasets they produce — lives in my shop: tg-crawl Pro (scraper wheel + daily-crawl recipes) and the free-form sample brief.
Top comments (2)
The byte-identical passthrough for users without the placeholder is an easy regression to overlook. Would you put that assertion beside a retry/resume test? That would document both the opt-in boundary and the per-run lifetime you found in the call sites.
Yes — adjacent, as a pair, and I'd name what each one protects so the suite reads as a contract:
The pairing is the point: passthrough proves the feature doesn't leak outward to non-users; retry/resume proves the rotation state doesn't leak sideways through the process lifecycle. Same failure family as the politeness thread today — per-worker budgets passing privately while the merged stream bursts — the property lives at the boundary, so the tests have to sit at boundaries too.
One ordering discipline that makes the pair self-documenting: run the passthrough assertion inside the retry test's setup phase as a precondition — resume the run, fire one no-placeholder request first, assert byte-identical, then exercise the rotating path. If the precondition trips, you know the regression is in shared client setup, not in the rotation logic, and the failure message localizes itself.
Both are ~15 lines against the fixture client — that's a cheap way to pin an expensive contract. Good instinct to want them next to each other.