fix(server): surface chat-template errors

[Odysseusailoon]

📋 PR Title

fix(server): surface chat-template errors

📝 Change Type

• fix: Bug fix.

💡 Description

Malformed chat requests that embed <|channel|> tags in messages[*].content caused the executor’s tokenizer step to raise a template error, leaving the scheduler hanging and never responding to the client. This PR forwards those failures back through the IPC channel so the HTTP handler can immediately return a structured 400 error while keeping the node healthy. It also adds unit coverage for the new HTTP error-handling path.

Key Changes

1. Add _notify_http_request_error in Executor to catch tokenizer/chat-template exceptions and send error envelopes to the HTTP server.
2. Extend HTTPHandler to track per-request error state, stream error chunks, and emit non-streaming 400 responses.
3. Manually test it on the machine.

🔗 Related Issues

• Closes [Bug]: Failed requests cause the node to be unavailable #158

[gufengc]

why not add jinja2 to dependency?

[Odysseusailoon]

jinja2 is only needed when a tokenizer uses a chat template that hits the Jinja renderer. The executor can run entirely without it (e.g., plain prompts, different tokenizers, or GPU builds in minimal environments), so we treat it as optional to keep install footprints small and avoid importing Jinja just to start the server.

The TemplateError handling is defensive: if jinja2 is present we surface a more precise error type to the HTTP handler; if it isn’t, we fall back to the generic exception. That lets tests and deployments without Jinja still run cleanly while giving better diagnostics where it’s installed.

[Odysseusailoon]

hi

[gufengc]

We do not want manual install some dependencies, so add it to dependency is a strightforward way.

[gufengc]

break?

[Odysseusailoon]

The continue after emitting the error chunk is intentional, it keeps the loop alive so the handler can pull whatever comes next (typically the None sentinel) and finish the stream cleanly.

if we change None → break so we exit the loop and send the final chunk + [DONE].
Error dict → emit the SSE error chunk, then continue so we don’t fall through to yield self._generate_stream_chunk(...) with a dict, and we keep waiting for the sentinel.

If we changed that continue to a break, an error would terminate the loop immediately: the client would miss the final [DONE], the request would never mark as finished in the streaming path, and it will leak resources if the sentinel never gets consumed.

[Odysseusailoon]

The continue after emitting the error chunk is intentional, it keeps the loop alive so the handler can pull whatever comes next (typically the None sentinel) and finish the stream cleanly.↳

if we change None → break so we exit the loop and send the final chunk + [DONE].
Error dict → emit the SSE error chunk, then continue so we don’t fall through to yield self._generate_stream_chunk(...) with a dict, and we keep waiting for the sentinel.

If we changed that continue to a break, an error would terminate the loop immediately: the client would miss the final [DONE], the request would never mark as finished in the streaming path, and it will leak resources if the sentinel never gets consumed.

[gufengc]

set default to None

[Odysseusailoon]

not neccesary, error_status is typed as HTTPStatus, and we default it to HTTPStatus.BAD_REQUEST so handle_executor_error() can always assign a valid status (or leave the default) and later create_error_response() can rely on a real HTTPStatus without adding None checks. Switching to None would force us to make the field Optional[HTTPStatus] and add guard code in every consumer, without any functional gain.

[gufengc]

Maybe set default to internal error is better as BAD_REQUEST will make client confused if it is not a bad request

[Odysseusailoon]

123