Hi — production checkout on benjiillustrated.com (site: benji-illustrated, ID 9b2c88df-8444-404e-8ca5-9fd7ddd549ae) has been silently broken since 2026-05-28T22:46 UTC, when the first deploy with bootstrap version 2.16.0 was published. No user-defined environment variables are reaching the function runtime — neither via process.env.X nor via Netlify.env.get("X"). AWS Lambda system vars and a few built-in NETLIFY_* vars (e.g. NETLIFY_BRANCH, URL) ARE present, so the bootstrap is partially injecting.
Reproduction (no Astro involvement): I deployed a minimal Netlify Functions v2 file at /netlify/functions/envcheck-raw.mts that just returns Object.keys(process.env) for the function process. None of the seven env vars configured in the Site → Environment variables UI (STRIPE_SECRET_KEY, STRIPE_PUBLISHABLE_KEY, STRIPE_WEBHOOK_SECRET, PRINTFUL_API_KEY, PRINTFUL_WEBHOOK_SECRET, RESEND_API_KEY, NETLIFY_BUILD_HOOK_URL) appear. All are configured with scopes including functions, and is_secret: false. The Netlify env-vars API confirms the values are correctly stored — they just aren’t being injected at runtime.
A Netlify Edge Function I deployed alongside it (/netlify/edge-functions/envcheck-edge.ts) DOES see all seven vars via Netlify.env.get(). So the issue is specifically the Serverless Functions v2 bootstrap path, not the env-var store or scoping.
Function metadata: runtimeAPIVersion: 2, bootstrapVersion: 2.16.0, invokeMode: stream, runtime nodejs20.x. The change from bs 2.15.0 (last seen 2026-05-25) to 2.16.0 correlates exactly with when env injection stopped working.
This appears identical to the issue acknowledged in https://answers.netlify.com/t/functions-v2-export-default-intermittently-missing-all-user-defined-env-vars-at-runtime/160958 (March 2026). A staff member reported a fix was rolled out on March 30, 2026; symptoms have returned for our site as of 2026-05-28.
Have put in Edge Functions for /api/checkout as a workaround in parallel. Would prefer a server-side fix from your end if possible.
Site ID: 9b2c88df-8444-404e-8ca5-9fd7ddd549ae.
Most recent confirmed-broken deploy: 6a1cc2d19cac2215fa6134ba (2026-05-31T23:22Z).