Five production bugs from running a 20-language AI song generator on Next.js A developer running a 20-locale AI song generator on Next.js 14 documented five silent production bugs, including a 411 MissingContentLength error caused by Next.js's patched fetch sending Buffer bodies without a Content-Length header to Cloudflare R2, and a consent-mode misconfiguration that left analytics_storage denied for all visitors and dropped nearly all post-landing-page tracking. The fixes involved signing R2 uploads with aws4fetch but sending them via axios with an explicit Content-Length, and re-applying stored consent choices before gtag config on every page load. A storage-expiry backfill also unexpectedly updated 2,122 rows instead of three, prompting the developer to recommend running a matching SELECT count(*) before any UPDATE. I run a small AI song generator: you paste lyrics, pick a style, and get a sung track back. It is a Next.js 14 App Router app with next-intl 20 locales , PostgreSQL, Cloudflare R2 for audio, and a third-party music API that calls back when a track is ready. This month I spent a few days fixing things that had been quietly wrong for a long time. None of them showed up as errors in the UI. Here are the five that were worth writing down. 411 MissingContentLength , but only inside Next.js Uploading the generated MP3 to R2 with the S3 API worked from a plain Node script. The same code inside a route handler failed: 411 MissingContentLength: You must provide the Content-Length HTTP header. The request was signed correctly. The problem was the transport: inside the Next.js server runtime, fetch which Next.js patches sent the Buffer body as a stream without a Content-Length header. R2 does not accept chunked uploads for a plain PUT . The fix was to keep aws4fetch for signing only, and send the request with a client that sets Content-Length from the buffer: python import { AwsClient } from "aws4fetch"; import axios from "axios"; const client = new AwsClient { accessKeyId, secretAccessKey, service: "s3", region: "auto" } ; export async function uploadToR2 key: string, body: Buffer { const url = https://${accountId}.r2.cloudflarestorage.com/${bucket}/${encodeURI key } ; // sign only; don't let the patched fetch send it const signed = await client.sign url, { method: "PUT", body, headers: { "Content-Type": "audio/mpeg", "Cache-Control": "public, max-age=31536000, immutable" }, } ; await axios.put url, body, { headers: Object.fromEntries signed.headers.entries , maxBodyLength: Infinity, } ; } The nasty part: my code caught the error and fell back to the external API's temporary URL, so songs played fine for a few days and then 404'd when those URLs expired. If you have a fallback path, log loudly when you take it. Analytics showed 709 page views for 714 sessions and more new users than users. In other words, almost nothing after the landing page was recorded. Two bugs together: analytics storage to denied for every visitor worldwide, not just where it is required. cookieConsent=true on both Accept and Decline, and only called gtag 'consent', 'update', … at the moment of the click. On the next page load the stored choice was never re-applied, so consent was back to The fix is to default to denied only in the regions that need it, store the actual choice, and re-apply it before config on every load: gtag 'consent', 'default', { analytics storage: 'denied', region: 'AT','BE', / … EEA, / 'GB','CH' } ; gtag 'consent', 'default', { analytics storage: 'granted' } ; var m = document.cookie.match / ?:^|; cookieConsent= granted|denied / ; if m gtag 'consent', 'update', { analytics storage: m 1 } ; gtag 'config', GA ID ; Old cookieConsent=true cookies are treated as "no choice yet", so those visitors see the banner once more. That is the honest option, since the old value can't tell you which button they pressed. Free-plan songs are now kept for 10 days. I added a column and a daily cleanup job: alter table works add column storage expire at timestamptz; create index idx works storage expire at on works storage expire at where storage expire at is not null; New free songs get now + interval '10 days' , and paid users get NULL kept forever . Then I backfilled existing free songs, expecting three rows. The UPDATE touched 2,122. My WHERE clause filtered on the user's plan and the song's status, but not on whether the audio still existed. Thousands of old songs whose files were long gone still had status = completed . Nothing was deleted, because the cleanup job had not run yet, and I reverted the 2,119 extra rows right away. Two habits came out of it: SELECT count with the exact same WHERE first, and compare it with the number you expect. --dry-run flag and logs what it would delete before it deletes anything. The music API calls POST /api/backend/sunoapi/