fix(production): keep the camera stream alive on Vercel - #15
Conversation
The prod frontend runs on Vercel, so this proxy is a serverless function with a wall-clock budget - and an MJPEG feed is a response that deliberately never ends. On the platform default (as little as 10s on some plans) the picture is cut off seconds after it appears, which reads as a broken camera rather than a platform limit. maxDuration raises that to the documented 300s ceiling. 300s is a ceiling, not a fix: the stream is still killed when it expires, about every five minutes. So the panel reconnects on its own, bounded at 20 consecutive attempts. Silently reconnecting is the honest response to a limit we know about - making the operator re-toggle every five minutes would be pretending it is their problem - while the bound stops a stream that fails instantly from spinning, and surfaces a genuine fault instead of retrying forever. Local development is unaffected: `next dev` has no such budget, which is why the camera works there and expires in production. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
1 participant
The prod frontend runs on Vercel, so the camera proxy is a serverless function with a wall-clock budget — and an MJPEG feed is a response that deliberately never ends. On the platform default (as little as 10s on some plans) the picture is cut off seconds after it appears, which reads as a broken camera rather than a platform limit.
This is also why it works locally and not in production:
next devhas no such budget.Changes
maxDuration = 300on the route — the documented ceiling300s is a ceiling, not a fix: the stream is still killed roughly every five minutes. Reconnecting silently is the honest response to a limit we know about — making the operator re-toggle every five minutes would be pretending it is their problem. The bound stops a stream that fails instantly from spinning, and surfaces a genuine fault instead of retrying forever.
Note on architecture
Proxying a continuous video feed through serverless functions is billed by duration and bandwidth (~0.6 MB/s at 2 fps). If the camera becomes something people leave open, the stream should bypass Vercel and go browser → Tensor-Core directly with a short-lived signed URL.
🤖 Generated with Claude Code