fix(ollama): cap num_ctx so it cannot wrap negative when cast to int32

[Anai-Guo]

What

applyOllamaOptions (core/http/endpoints/ollama/helpers.go) copied a client-supplied options.num_ctx straight into cfg.ContextSize with only a > 0 check:

if opts.NumCtx > 0 {
    cfg.ContextSize = &opts.NumCtx
}

That value is later cast to int32 before it reaches the backend (ContextSize: int32(ctxSize) in core/backend/options.go), so a num_ctx above math.MaxInt32 silently wraps into a negative context size that is then sent to the backend's LoadModel gRPC call. Both /api/chat and /api/generate route through applyOllamaOptions, so both Ollama-compatible endpoints shared the defect.

Fixes #11022.

Change

• Cap num_ctx at math.MaxInt32 in applyOllamaOptions so the later int32 cast always stays positive.
• Add helpers_internal_test.go (internal package ollama so it can exercise the unexported helper) with regression coverage for the overflow, in-range, and unset cases.

Scope note

num_ctx is an intentional user override in the Ollama API, so this change deliberately does not re-impose the hardware-aware autoContextSize clamp as an upper bound — applyOllamaOptions has no access to the loaded GGUF, and whether a user override should be allowed to exceed the auto-derived size is a policy decision. This PR only removes the silent negative-wrap. Happy to extend it if maintainers prefer a hardware-aware ceiling.

🤖 Generated with Claude Code

[localai-org-maint-bot]

The int32 overflow guard is useful, but this does not fix the primary bug reported in #11022. Capping to math.MaxInt32 still lets an unauthenticated request replace the hardware/model-derived context limit with ~2.1 billion tokens, so a real backend can still attempt a catastrophic KV-cache allocation. cfg.ContextSize has already been populated by model configuration / hardware-aware defaults before applyOllamaOptions runs; please treat that existing positive value as the server ceiling and clamp options.num_ctx to it (while retaining an int32-safe bound for configurations where no smaller ceiling exists). Add regression coverage where an oversized but in-range value such as 2,000,000,000 cannot replace an existing 4096/8192 ceiling, for both shared /api/chat and /api/generate option handling. The current test only proves the secondary overflow symptom and would pass while the DoS remains.

[Anai-Guo]

Thanks — you're right that the MaxInt32 cap only addressed the overflow symptom, not the DoS. Updated in 41faba3:

• applyOllamaOptions now treats any existing positive cfg.ContextSize (populated by model config / hardware-aware defaults before this runs) as the server ceiling and clamps options.num_ctx down to it. A request can no longer raise the context window, so num_ctx=2,000,000,000 against a 4096/8192 model can't trigger a catastrophic KV-cache allocation. A smaller num_ctx is still honored.
• The math.MaxInt32 bound is retained for the case where no smaller ceiling exists, keeping the later int32 cast safe.
• Since /api/chat and /api/generate share applyOllamaOptions, both paths are covered by one fix. Added regression specs proving num_ctx=2,000,000,000 is clamped to an existing 4096 and 8192 ceiling (not replacing it), plus a spec that a smaller value still passes through.