#nextjs

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Ryu Hi ya2s, I'd treat this as a limitation of combining a plain Multi-Zone rewrite with Vercel Authentication on the destination project. A rewrite can keep the browser URL on Project A for normal traffic, but once Project B's Deployment Protection challenges the request, the auth flow belongs to Project B. That means the redirect/cookie flow can reasonably end up on Project B's deployment/custom domain instead of staying fully masked behind Project A. For the architecture you want, I don't think a vercel.json rewrite alone is the right layer, because it can't safely attach a private bypass secre

Vinaydabas611 40 viewers/day is low for 3h50 of CPU, so before pinning it on crawlers or compute, confirm your actual request count in the logs. If it's far above your real traffic, the usual hidden cause is your own app re-firing server renders --- a router.refresh() / auto-refresh on tab focus or navigation, aggressive client-side polling, or default prefetch firing a burst of RSC requests on every page. (A third-party uptime monitor on a tight interval does the same.) The tell is a repeating, multi-route request pattern in the logs that no human would produce. If real crawlers are a big share: a robots.t

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryu Hi Adeline, Your suspicion sounds pretty reasonable. When an AI app grows from "one prompt generates everything" into multiple muses, menus, timelines, variations, etc., the fragile part is usually that too much decision-making is left inside the prompt. I'd separate this into a more deterministic pipeline: User selects / describes the party App deterministically chooses the muse/theme metadata from a fixed JSON or database table AI generates only the sections that actually need language generation Output is validated against a schema Failed or mismatched sections are retried individually, not

Rperrings Same error, different stack, can confirm this is happening on our project too. Project: coordinator (team_vGTARzIqepot5z7oHepmJ8qL, project prj_yry9y58eDTvmbfcbluQ45IDptpGH) Framework: Next.js 16.2.6 Vercel builder version 54.3.0 (same as yours) Identical TypeError on Applying modifyConfig from Vercel. Started \~14:00 UTC today. Empty commits reproduce the failure. Local npm run build and vercel build --prod both succeed. Our stack differs from yours (no custom domain change today, no Sentry+PWA+BundleAnalyzer wrapper). So the trigger may not be specific to the domain attachment you flagged --

Ryu Hi shh, The important clue is that the build output is created under: /vercel/path0/web/.next but the final error is looking for: /vercel/path0/.next/routes-manifest-deterministic.json So I’d treat this as a post-build/finalization path issue before changing the app code. If next build and static generation already complete successfully, the app build itself is probably not the failing layer. A good isolation test is to bypass Git Integration once and deploy a prebuilt output from the app root: cd web vercel pull --yes --environment=production vercel build --prod vercel deploy --prebuilt --arc

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryu Hi, Your CAA suspicion is worth checking. Vercel's domain troubleshooting docs say Vercel uses Let's Encrypt for automatic SSL certificates, and if any CAA records already exist on the domain, the domain needs to allow letsencrypt.org. A couple of things I would verify: Run: dig -t CAA +noall +ans bmudpt.xyz Confirm whether the domain has only pki.goog, or whether letsencrypt.org is also present. If CAA records are managed through Vercel DNS and you cannot remove/edit the pki.goog record, this may need Vercel staff to inspect the DNS zone. Also check the domain in Let's Debug or DNSViz, since

Ryu Hi, The important part of the error is: File URLs can not be larger than 32 MB So the request is likely being rejected by the file URL / attachment path before the model can process the PDF. Since \~30 MB files work and larger files fail, I would treat 32 MB as the practical limit for this URL-based attachment flow unless the AI SDK/Azure provider team confirms otherwise. For larger PDFs, I would avoid sending the entire file inline through useChat. A more reliable pattern is: Upload the PDF separately. Parse or extract the PDF text server-side. Split the text into chunks. Send only the releva