Repository navigation
Server unstable? #2
Description
I did some quick tests and encountered this strange bug (sorry for no reproduction code yet - I hope I can deliver that soon):
ok what does this mean? the gemma repo is just buggy?
• I’ll inspect the server’s own log around the rejection; that distinguishes an input validation error from a state/cache failure in the native server.
• Waited for background terminal · XDG_CACHE_HOME="$PWD/.cache" ./bin/embeddinggemma
• It points to a bug or unstable state in the embeddinggemma.c HTTP server, not a bad SciDocs document or a model-quality issue.
Evidence:
- The same 8 requests all return HTTP 200 when retried individually.
- The same batch also returns HTTP 200.
- Failures occur only after thousands of prior requests.
- The server emits no diagnostic body/log for the HTTP 400 and remains able to serve later requests.
So the likely fault is stateful request handling—e.g. its cache, queue, or connection management—not embedding semantics. I would not discard Gemma; I would
benchmark it with checkpointed embeddings and automatic server restart/retry on transient 400s, rather than assuming a particular document is invalid.
Activity
ehartford commentedon Oct 18, 2026
Thanks for the report, and your agent's read was right: it was a bug in the HTTP server, not your documents or the model.
Cause. The server applied its keep-alive idle timeout (1 second) to every read on a connection, including reads in the middle of a request. If your client paused for more than a second between sending the request headers and the body, or partway through a large body, the server gave up, answered
400, and logged nothing. The same request then succeeded on retry. A normal client sends headers and body together, so this only fires on an occasional stall: a GC or scheduling pause in a busy client, a slow proxy, or curl'sExpect: 100-continuehandshake on bodies over 1 KB, which the server never answered. That fits "only after thousands of requests" and a few failing together.I reproduced it on v0.3.1 and on main: a request with a 1.3 s pause between headers and body gets
400, with a 0.2 s pause it gets200.Fix in #8:
--request-timeout-ms); a request that really stalls gets408, not400.Expect: 100-continueis answered properly.500, not400.Until it's released, a client-side retry on these 400s is a safe workaround. If you still see one with the fix, the server's stderr line will say exactly why, and I'd like to see it.