Stream AI Service response while using Function Calling

[HakimMohammed]

I am using LangChain to build an AI assistant with Mistral AI as the provider. I provided the assistant with tools ( mostly repositories so that he can get data from the database ).

When I set the response type to String

String chat(@MemoryId String memoryId, @UserMessage String userMessage);

The assistant works perfectly. But when I try to enable response streaming by using Multi<String>

Multi<String> chat(@MemoryId String memoryId, @UserMessage String userMessage);

I get this error

2026-06-08 10:41:08,865 ERROR [io.quarkus.mutiny.runtime.MutinyInfrastructure] (vert.x-eventloop-thread-3) Mutiny had to drop the following exception: java.lang.NullPointerException: Cannot invoke "java.util.List.iterator()" because the return value of "dev.langchain4j.model.mistralai.internal.api.MistralAiDeltaMessage.getContent()" is null
        at io.quarkiverse.langchain4j.mistralai.QuarkusMistralAiClient$2.accept(QuarkusMistralAiClient.java:89)
        at io.quarkiverse.langchain4j.mistralai.QuarkusMistralAiClient$2.accept(QuarkusMistralAiClient.java:83)
        at io.smallrye.mutiny.subscription.Subscribers$CallbackBasedSubscriber.onItem(Subscribers.java:79)
        at io.smallrye.mutiny.operators.multi.builders.BufferItemMultiEmitter.drain(BufferItemMultiEmitter.java:123)
        at io.smallrye.mutiny.operators.multi.builders.BufferItemMultiEmitter.emit(BufferItemMultiEmitter.java:37)
        at io.smallrye.mutiny.operators.multi.builders.SerializedMultiEmitter.onItem(SerializedMultiEmitter.java:51)
        at io.smallrye.mutiny.operators.multi.builders.SerializedMultiEmitter.emit(SerializedMultiEmitter.java:141)
        at org.jboss.resteasy.reactive.client.impl.MultiInvoker$MultiRequest.emit(MultiInvoker.java:77)
        at org.jboss.resteasy.reactive.client.impl.MultiInvoker.lambda$registerForSse$2(MultiInvoker.java:248)
        at org.jboss.resteasy.reactive.client.impl.SseEventSourceImpl.fireEvent(SseEventSourceImpl.java:231)
        at org.jboss.resteasy.reactive.client.impl.SseParser.dispatchEvent(SseParser.java:181)
        at org.jboss.resteasy.reactive.client.impl.SseParser.parseEvent(SseParser.java:155)
        at org.jboss.resteasy.reactive.client.impl.SseParser.handle(SseParser.java:115)
        at org.jboss.resteasy.reactive.client.impl.SseParser.handle(SseParser.java:11)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:270)
        at io.vertx.core.http.impl.HttpEventHandler.handleChunk(HttpEventHandler.java:51)
        at io.vertx.core.http.impl.HttpClientResponseImpl.handleChunk(HttpClientResponseImpl.java:239)
        at io.vertx.core.http.impl.Http1xClientConnection$StreamImpl.lambda$new$0(Http1xClientConnection.java:456)
        at io.vertx.core.streams.impl.InboundBuffer.handleEvent(InboundBuffer.java:279)
        at io.vertx.core.streams.impl.InboundBuffer.drain(InboundBuffer.java:266)
        at io.vertx.core.streams.impl.InboundBuffer.lambda$asyncDrain$1(InboundBuffer.java:317)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:270)
        at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:252)
        at io.vertx.core.impl.ContextInternal.lambda$runOnContext$0(ContextInternal.java:50)
        at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:173)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:166)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:569)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:998)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:1583)

[cescoffier]

Could you open an issue in the quarkus-langchain4j project? Sounds like a bug.

[HakimMohammed]

I contributed and provided a fix for it. It is already merged to main.

[MILLERMARRU]

The NPE is specific to how the Mistral streaming adapter parses delta chunks, not to Multi<String> or Quarkus LangChain4j's streaming abstraction in general. Multi<String>/Multi<ChatEvent> streaming is documented as working with tools (the function-calling guide shows a Multi<Fraud> example combined with @ToolBox), so the abstraction itself isn't the problem.

What's actually happening: when Mistral's streaming API executes a tool call, the delta chunks it sends for that turn carry tool_calls and omit content entirely (this mirrors OpenAI's delta format, it's expected behavior from the API, not malformed data). Your stack trace shows QuarkusMistralAiClient$2.accept calling .getContent().iterator() directly on the delta, which assumes content is always present. It isn't, on a tool-call delta, so you get exactly this NPE. This is a gap in the Mistral client's SSE parsing, not in your Multi<String> method signature.

Since switching to Multi<ChatEvent> wouldn't help here (the crash happens in the raw SSE parsing layer, before your AI service method's return type is even relevant), the practical options while this gets fixed:

• Fall back to the blocking String signature specifically for the tool-enabled path, and only stream for turns you know won't invoke a tool. You already confirmed the blocking version works.
• If you need streaming end to end regardless of tool calls, an OpenAI-compatible provider (or Mistral's OpenAI-compatible endpoint, if you're not already using it) is worth trying, since that code path has had more mileage with mixed content/tool_calls deltas.

When you open the issue, pointing at QuarkusMistralAiClient.java:89 and noting that the delta's content is null specifically on tool-call chunks should make it a quick fix, it looks like a one-line null guard around that iterator call.