Stripe SDK: stripe.products.create throws 'replace is not a function' (request dispatch, flat body) after #4831

[proggeramlug]

Summary

After #4831 fixed Stripe SDK method dispatch, calling a Stripe SDK method (e.g. stripe.products.create({ name })) now reaches the request layer but throws TypeError: replace is not a function — even for a flat request body. So Stripe requests still fail end-to-end on Perry.

Repro (verified on Linux; makes a real Stripe test-mode call)

import Stripe from "stripe";
const s = new Stripe(process.env.STRIPE_SECRET_KEY as string, {});
try {
  const p = await s.products.create({ name: "Perry Repro DELETE" });
  console.log("OK product id:", p.id);
} catch (e: any) {
  console.log("ERR:", e?.name, e?.message);
  console.log("STACK:", e?.stack);
}

STRIPE_SECRET_KEY=sk_test_... perry compile striperepro.ts -o striperepro && ./striperepro

Actual (bug)

ERR: TypeError replace is not a function
STACK: TypeError: replace is not a function
    at <anonymous>

(e.stack collapses to at <anonymous> — see note below; a real JS stack would help a lot here.)

Localization done so far

Stripe (cjs build) has exactly 5 .replace( sites; I instrumented the three that a flat products.create would hit and none of them executed before the throw:

• StripeResource.js _joinUrlParts — parts.join('/').replace(...) (path build) — never logged
• utils.js queryStringifyRequestData — qs.stringify(data,...).replace(...) (body encode) — never logged
• utils.js makeURLInterpolator — str.replace(...) (path interpolation) — never logged

So the failing .replace is upstream of path-building and body-encoding — i.e. in the request dispatch (stripeMethod → makeRequest → _request), header/User-Agent setup, or a transitive dependency reached before those. The receiver is a non-string value whose .replace is undefined (a TypeError: ... is not a function, not Cannot read properties of undefined).

This may share a root cause with #4831 (cross-module extend dispatch) — the dispatched method may receive an argument/this of the wrong type, so a value the SDK expects to be a string is something else.

Secondary (separate, filed as #4840)

qs.stringify on nested bodies throws Constructor WeakMap requires 'new' — will block subscription/checkout calls (nested items/line_items) once this replace issue is resolved.

Ask

A readable JS stack for uncaught TypeErrors in compiled binaries would make this trivial to localize (currently Error.stack is just at <anonymous>). Otherwise, reproducing the stripeMethod/extend request path with a flat body should surface it.

Environment

• Linux x86_64 (Ubuntu 24.04)
• perry main @ 827bfd50c (includes Stripe Node SDK: all resource methods undefined (stripe.products.create etc. is not a function) #4831)
• stripe ^17.x (cjs)

[proggeramlug]

Fixed by #4849 (e4ab64f7b), which landed on main.

Root cause was the same closure-identity bug as the #4831 follow-up — not a string/.replace issue per se. Stripe builds every resource with:

const Constructor = function (...a) { Super.apply(this, a); };
Constructor.prototype = Object.create(Super.prototype);
Object.assign(Constructor.prototype, methods); // {create, retrieve, …}

That capture-less/const-capturing non-arrow function expression was allocated as a single shared closure object — and therefore a single shared .prototype — for every evaluation. So all resources aliased one prototype, each Object.assign clobbered the previous resource's methods, and every stripe.<resource>.<method> resolved to the last-registered resource (products.create actually ran webhook_endpoints' method). On Linux the wrong/garbage spec was a non-string ⇒ replace is not a function; on macOS the allocator retained valid memory so it silently hit the wrong endpoint.

#4849 gives such function expressions fresh identity (and a fresh .prototype) per evaluation. Verified: with the fix, stripe.products.create({ name }) now dispatches to /v1/products and reaches Stripe's server (a dummy key returns a normal auth error) instead of crashing.

Note on the localization in this issue: the .replace sites that 'never logged' did in fact run — Perry resolves npm import via the package exports import condition, so it compiles Stripe's ESM build (esm/), and the console.log probes added to the cjs/ tree were never compiled.

Two separate pre-existing async-rejection bugs surfaced while debugging (a handled return Promise.reject() still reported as unhandled; and an async HTTP rejection not caught by a surrounding await try/catch). Filing those separately. The readable-stack 'Ask' is partially addressed by a follow-up that prints the rejection reason (Uncaught (in promise) TypeError: …) instead of the bare line.

Closing as fixed.

[proggeramlug]

Root-caused: the real primitive is String.prototype.match with the /g flag segfaulting on a no-match — see the minimal repro "abc".match(/x/g) in #4858. Stripe's extractUrlParams does path.match(/\\{\\w+\\}/g) on every request; for paths without {params} this crashes (surfaces here as 'replace is not a function').

[proggeramlug]

Definitive localization (rebuilt at ec30493, incl. #4868 Function parity; still fails): instrumented the first line of the stripeMethod-returned function (StripeMethod.js, before extractUrlParams/createResourcePathWithSymbols) with confirmed-compiled DBG logging, PERRY_NO_CACHE=1, compile_exit=0. The method-body entry never logs — stripe.products.create({name}) throws TypeError: replace is not a function before any Stripe JS executes. The methods exist (typeof === 'function', per #4831), but invoking a protoExtend-defined method fails inside perry's native call/dispatch path. So this is a runtime/codegen bug in the method-call lowering for protoExtend-defined methods, not in Stripe's JS. Repro unchanged: stripe.products.create({name}). Reproduces on every Stripe resource method.

[proggeramlug]

Root-caused and fixed in #4874.

It is a real bug, but the method body does run — the earlier "throws before any Stripe JS executes" localization was off. Instrumenting the actual synchronous path on Linux showed the method body entering normally; the throw is inside _makeRequest → queryStringifyRequestData:

// stripe/esm/utils.js
export function queryStringifyRequestData(data, apiMode) {
    return (qs.stringify(data, {...}).replace(/%5B/g, '[').replace(/%5D/g, ']'));
    //      ^^^^^^^^^^^^^^^^^^^^^^^^ returned a *function*, not a string
}

qs.stringify(...) returned the qs stringify function instead of a string, so .replace was undefined ⇒ TypeError: replace is not a function.

Why: Stripe's utils.js does import * as qs from 'qs' and calls qs.stringify. qs/lib/index.js is CommonJS (var stringify = require('./stringify'); module.exports = { stringify }, where ./stringify is module.exports = function (...)). Perry's import * as namespace-member classifier keyed the var-vs-function check only on (origin_path, "stringify") and missed the submodule's synthetic (origin_path, "default") entry — so it treated the member as a function and wrapped the default getter in a singleton closure. Calling ns.stringify(args) then returned the function rather than invoking it. The default import (import qs from 'qs') was unaffected — only import * as was broken.

Minimal repro (no Stripe needed):

// node_modules/mini/index.js : var sfy = require('./sfy'); module.exports = { sfy };
// node_modules/mini/sfy.js   : module.exports = function (o) { return "S:" + o; };
import * as m from "mini";
(m as any).sfy("X");   // before: a function (len 0); after: "S:X"

Fix (#4874): the namespace arm now probes both (origin_path, member) and (origin_path, origin_name) against the exported-var set, mirroring the named-import arm. Verified on Linux x86_64: with the fix, stripe.products.create({ name }) builds and dispatches the request and reaches Stripe's API (a dummy key would return a normal auth error) instead of throwing — qs.stringify({a:1,b:'x'}) now returns "a=1&b=x".

Note: the "unsettled top-level await" when awaiting the real network call is the separate pre-existing async-HTTP-settling issue already called out here (and #4840 for nested bodies) — not this .replace bug.