The app prints a green "Kimodo model loaded on RunPod GPU" success line on startup without ever contacting the pod. When the pod is down, the user sees a confirmation that the backend is ready, then a hard failure on their first click.
The bug
// app.js:2086
log('Kimodo model loaded on RunPod GPU', 'success');
That call is unconditional, at module init. It is not inside a .then(), not guarded by a response, not retried.
The backend does expose a real health endpoint:
# scripts/server_fast.py:42
@app.get("/health")
but nothing calls it. grep -c "/health" app.js returns 0.
What the user experiences
what the log says what is actually true
[OK] Kimodo model loaded GET /health -> 404
on RunPod GPU (pod is stopped)
| |
v v
user types a prompt ------------> fetch to app.js:1915 fails
|
v
"Error: Unexpected end of JSON input"
The error text is itself wrong, which makes the confusion worse: app.js:1919 calls .json() on the 404's empty body, so instead of "the backend is unreachable" the user gets a JSON parse error.
Why it matters
This is the first thing on screen in a demo. Claiming a GPU model is loaded when nothing was checked is a false statement in the product's own UI, and it converts a clean "backend is offline" message into a mystery.
Fix
Replace the unconditional log with a real probe, with a short timeout since there is currently no AbortController anywhere in app.js:
const ctl = new AbortController();
setTimeout(() => ctl.abort(), 3000);
try {
const r = await fetch(`${API}/health`, { signal: ctl.signal });
log(r.ok ? 'Kimodo model loaded on RunPod GPU'
: 'Motion backend unreachable — running without motion generation',
r.ok ? 'success' : 'warn');
} catch {
log('Motion backend unreachable — running without motion generation', 'warn');
}
And fix app.js:1919 to read the body as text before assuming JSON.
The app prints a green "Kimodo model loaded on RunPod GPU" success line on startup without ever contacting the pod. When the pod is down, the user sees a confirmation that the backend is ready, then a hard failure on their first click.
The bug
That call is unconditional, at module init. It is not inside a
.then(), not guarded by a response, not retried.The backend does expose a real health endpoint:
but nothing calls it.
grep -c "/health" app.jsreturns 0.What the user experiences
The error text is itself wrong, which makes the confusion worse:
app.js:1919calls.json()on the 404's empty body, so instead of "the backend is unreachable" the user gets a JSON parse error.Why it matters
This is the first thing on screen in a demo. Claiming a GPU model is loaded when nothing was checked is a false statement in the product's own UI, and it converts a clean "backend is offline" message into a mystery.
Fix
Replace the unconditional log with a real probe, with a short timeout since there is currently no
AbortControlleranywhere inapp.js:And fix
app.js:1919to read the body as text before assuming JSON.