## Issue
Related to #5789
## Change
`ApacheHttpClient` builds the underlying Apache HttpClient 5 sync/async
clients from `HttpClients.custom()` / `HttpAsyncClients.custom()`, which
have `automaticRetriesDisabled = false` by default. As a result,
Apache's `DefaultHttpRequestRetryStrategy` transparently retries
requests (e.g. on connection failures and on HTTP `429`/`503`)
**underneath** LangChain4j's own retry logic. This has two consequences:
- `maxRetries=0` does not actually disable retries — Apache still
retries at the transport level.
- For any `maxRetries` value, retries are effectively stacked
(LangChain4j retries × Apache retries).
This PR makes LangChain4j the single source of truth for retry behavior:
when `ApacheHttpClient` creates the client builders itself, it now calls
`disableAutomaticRetries()` on both the sync and async
builders.
To avoid overriding an explicit user choice, this is only applied to the
**default (LangChain4j-created) builders**. If a user supplies their own
`httpClientBuilder`/`httpAsyncClientBuilder`, their retry
configuration is left untouched — they remain free to configure retries
as they wish (and can call `disableAutomaticRetries()` themselves if
they want LangChain4j to be the only retry layer).
**Note on behavior:** for users on the default builder who were (often
unknowingly) relying on Apache's implicit retries, those transport-level
retries are no longer performed; retries are now governed solely
by LangChain4j's `maxRetries`. No public API changes (verified with
`revapi:check`).
This mirrors the Spring-side fix for `SpringRestClient` in
langchain4j/langchain4j-spring#200.
### Tests
Added `ApacheHttpClientRetriesIT` (WireMock, always returns `503`),
covering both cases:
- default builder → exactly **1** request is made (no transport-level
retry);
- user-supplied builder with an explicit
`DefaultHttpRequestRetryStrategy(2, …)` → **3** requests are made (1
initial + 2 retries), i.e. the user's configuration is honored.
No new dependencies were added (WireMock is already a test dependency
across modules).
## General checklist
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langch 1 new message (ctrl+End) ↓
ig" features)
## Issue
Closes#5808
## Change
`JdkHttpClient.readBody(HttpResponse<InputStream>)` builds the
`HttpException` message that streaming (SSE) callers receive through
`listener.onError()`. It read the stream with
`reader.lines().collect(joining(System.lineSeparator()))`, which drops
the original line separators and the trailing one, and its
`InputStreamReader` had no charset, so decoding fell back to the JVM
default.
The synchronous path in the same class (`execute(HttpRequest)`) already
does `new String(body, UTF_8)`. This change makes the streaming path
match:
```java
try (InputStream inputStream = response.body()) {
return new String(inputStream.readAllBytes(), StandardCharsets.UTF_8);
}
```
Three now-unused imports (`BufferedReader`, `InputStreamReader`,
`Collectors.joining`) are removed. Nothing else in the file changes.
New unit test `JdkHttpClientErrorBodyTest` (WireMock, no API key) stubs
a `400` with body `line1\r\nline2\r\n` and asserts the exception message
matches exactly. It fails before this change (`line1\nline2`) regardless
of the JVM default charset.
`ApacheHttpClient.readBody` has the same pattern. It is left alone so
this one can be reviewed first.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
Unit tests in the module are green (9 tests). `JdkHttpClientIT` and
`JdkHttpClientTimeoutIT` were not run locally because they need external
services.
- [X] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Will be added after approval, per the contribution guide -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
<!-- N/A - internal bug fix, no example needed -->
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
<!-- N/A - unrelated to Spring Boot starters -->
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Issue
Closes#5805
## Change
`ApacheHttpClient` passed the SPI `connectTimeout` to
`RequestConfig.Builder.setConnectionRequestTimeout`, which limits
waiting for a pooled connection, not connection establishment.
Establishment reads `RequestConfig.getConnectTimeout()`, never set here,
so the connection manager fell back to the `ConnectionConfig` default of
3 minutes. `JdkHttpClient` and `OkHttpClient` map the same value to the
real connection timeout.
The mapping is replaced; the pool lease timeout returns to the Apache
default.
```java
if (builder.connectTimeout() != null) {
setConnectTimeout(requestConfigBuilder, builder.connectTimeout());
}
```
The `RequestConfig` is shared by the sync and async client builders, so
both paths are covered.
`RequestConfig.Builder.setConnectTimeout` is deprecated, hence
`@SuppressWarnings("deprecation")` on a small private helper. Its
`ConnectionConfig` replacement can only be applied through a connection
manager, which would override the one a user passes via
`httpClientBuilder(...)`. httpclient5 gives
`RequestConfig.getConnectTimeout()` precedence over `ConnectionConfig`
when it is set.
Testing: a delegating `HttpClientConnectionManager` spy asserts the
`Timeout` passed to `connect(...)` on a real request to WireMock
localhost — null when unset, the configured value when set. Whether the
timeout fires on a slow connection is not covered: WireMock cannot
simulate connection timeouts.
No text conflict with the open draft #5527, which touches the same file
but not this block; I will rebase if it merges first.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
<!-- Unit tests green (8/8, JDK 17). The module integration tests were
not run locally: they need network/external services. -->
- [X] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Unit tests only, via `-pl langchain4j-core,langchain4j clean test`.
-->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
<!-- N/A — docs are added after review per the template -->
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
<!-- N/A — bug fix, not a feature -->
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!-- N/A — no public API change -->
## Issue
Closes#5804
## Change
The streaming path used `fromOkHttpResponse(response)`, the converter
written for the synchronous path. That converter calls
`response.body().bytes()` unless the `Content-Type` is
`text/event-stream`, which reads the body to the end and closes it. The
parser then reads the same body, fails with `IOException: closed`, and
the listener receives no events. Servers that stream with another media
type hit this, for example Ollama with `application/x-ndjson`.
`fromOkHttpResponse` is now split into an overload that takes the body
bytes, and the streaming path passes `null`, the same way
`JdkHttpClient` calls `fromJdkResponse(jdkResponse, null)`.
```java
SuccessfulHttpResponse successResponse = fromOkHttpResponse(response, null);
```
The synchronous path is unchanged, and non-2xx responses are still
handled earlier by `readBody(response)`.
`OkHttpClientStreamingTest` serves responses from
`com.sun.net.httpserver.HttpServer`, so it needs no API key. It covers
the streaming path with `application/x-ndjson`, with
`text/event-stream`, with no `Content-Type`, and with a 500 response,
plus the synchronous path with and without `text/event-stream`.
Reverting the fix makes the two non-SSE streaming tests fail with
`IOException: closed`.
The import reordering and line-wrapping in the diff come from
`spotless:apply` (palantir), which reformats the whole file once it is
touched.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
<!-- The two *IT classes in this module (OkHttpClientIT,
OkHttpClientTimeoutIT) require OPENAI_API_KEY and were not run. -->
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- langchain4j-core was built and tested as part of the -am build and
is green; the langchain4j main module was not run. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
<!-- Behaviour fix, no documentation change. -->
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
<!-- Bug fix. -->
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!-- No starter is affected. -->
## Summary
Adds **Text-to-Speech (TTS)** support to LangChain4j: a new
provider-agnostic `TextToSpeechModel` abstraction in `langchain4j-core`,
an OpenAI implementation backed by the [OpenAI Speech
API](https://platform.openai.com/docs/api-reference/audio/createSpeech),
and the HTTP-client plumbing needed to return binary (audio) response
bodies intact.
## Changes
### `langchain4j-core` — new abstraction (`dev.langchain4j.model.audio`,
`@Experimental`)
- **`TextToSpeechModel`** — interface mirroring the existing
`AudioTranscriptionModel`:
- `synthesize(String text)` — convenience method using the model's
default voice
- `synthesize(TextToSpeechRequest request)`
- `provider()` defaulting to `OTHER`
- **`TextToSpeechRequest`** — carries `text` (validated non-blank) and
optional `voice`
- **`TextToSpeechResponse`** — wraps the core `Audio` type;
`from(Audio)` factory
### `langchain4j-open-ai` — OpenAI implementation
- **`OpenAiTextToSpeechModel`** — configurable `modelName`, `voice`
(default `alloy`), `timeout`, `maxRetries` (default `2`),
request/response logging, custom `baseUrl`, and `httpClientBuilder`.
Enforces
OpenAI's 4096-character input limit. `provider()` → `OPEN_AI`.
- **`OpenAiTextToSpeechModelName`** — `tts-1`, `tts-1-hd`,
`gpt-4o-mini-tts`, `gpt-4o-mini-tts-2025-12-15`
- **`OpenAiTextToSpeechRequest` / `OpenAiTextToSpeechResponse`** —
internal DTOs (`internal.audio.texttospeech`); the response is built
from the raw HTTP body (binary audio, not JSON)
- **`OpenAiTextToSpeechModelBuilderFactory`** — SPI factory for builder
customization
- **`OpenAiClient.textToSpeech(...)`** — `POST /audio/speech`, mapping
the raw bytes + `Content-Type` into the response
### HTTP client layer (shared) — binary response support
- **`SuccessfulHttpResponse`** — body is now stored as `byte[]`.
`body()` is preserved and returns a decoded `String` (using the charset
from the `Content-Type` header, UTF-8 fallback); adds `bodyBytes()` for
raw binary access and `contentType()`. The `body(String)` builder is
kept and a `body(byte[])` overload added — **additive, no public method
removed or changed**.
- **`JdkHttpClient`** — switched to `BodyHandlers.ofByteArray()`;
**`ApacheHttpClient` / `OkHttpClient`** read the body as raw bytes, so
binary payloads (audio) are no longer corrupted by text decoding.
- **`HttpResponseLogger`** — no longer decodes/dumps binary bodies as
text; logs `[binary body, N bytes, content-type: ...]` instead.
### Tests
- Core: `TextToSpeechModelTest`, `TextToSpeechRequestTest`
- HTTP: `SuccessfulHttpResponseTest` (charset decoding/edge cases),
`HttpClientIT` binary-response test asserting a valid MP3 is returned
across all client implementations
- OpenAI: `OpenAiTextToSpeechModelTest` (input-length and required-field
validation), `OpenAiTextToSpeechModelIT` (parameterized over every
supported model)
### Docs & API compatibility
- Added a **"Creating `OpenAiTextToSpeechModel`"** section to the OpenAI
docs page
- `revapi.json` updated to acknowledge the core
`TextToSpeechRequest`/`TextToSpeechResponse` types intentionally exposed
by `OpenAiTextToSpeechModel`
## Design notes
- Named `TextToSpeechModel` / `synthesize(...)` for discoverability (TTS
is the universally recognized term) and to read as a clear inverse of
the existing `AudioTranscriptionModel` / `transcribe(...)`.
- The shared HTTP-client change is **behavior-preserving**: for every
client (JDK / Apache / OkHttp), responses without an explicit charset
were already decoded as UTF-8, and explicit charsets are still
honored — verified empirically against `httpclient5 5.6.1` / `httpcore5
5.4`. The `String → byte[]` move is additive at the public API level.
## General checklist
- [x] There are no breaking changes (API, behaviour) — the shared
`SuccessfulHttpResponse` change is additive and verified
behavior-preserving; please review the HTTP-client layer regardless, as
it affects all
providers
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [x] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
---------
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
Hi! I'm Mohit, I work at TwelveLabs (@mohit-twelvelabs).
## Issue
N/A — small standalone fix.
## Change
This PR has been **trimmed down** to a single, self-contained core fix,
following @glaforge's feedback that the TwelveLabs integration itself
belongs in `langchain4j-community`. The integration has moved to
langchain4j/langchain4j-community#706; this PR now contains only the
core bug fix that I found underneath it.
**The fix:** the JDK `HttpClient` built `multipart/form-data` request
bodies but never set the `Content-Type` header (with the boundary), so
servers that parse multipart requests rejected them (e.g.
`content_type_invalid`). The OkHttp and Apache clients already set this
header — this brings the JDK client in line.
- `JdkHttpClient` now sets `Content-Type: multipart/form-data;
boundary=...` whenever the request carries form-data fields or files.
- `MultipartBodyPublisher.contentType()` exposes the boundary-bearing
header value so the body and header always agree.
- Added a regression test asserting the advertised boundary matches the
one used to delimit the body.
This is **non-breaking and additive** — it only adds a header that was
previously missing on multipart requests; no existing behaviour changes.
### How it was tested
- `MultipartBodyPublisherTest` — added a regression test for the
`Content-Type`/boundary fix; all JDK http-client unit tests are green.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
---------
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
## Issue
Closes#5466
## Change
`MultipartBodyPublisher.addFile` in `langchain4j-http-client-apache`
concatenated `"Content-Type: " + file.contentType()` into the part
header unguarded, emitting a literal `Content-Type: null` line for null
and an empty `Content-Type:` for blank — both malformed multipart. This
is reachable on a normal path: `Audio.mimeType()` is null when unset and
`DefaultOpenAiClient.audioTranscription()` forwards `file.mimeType()`
unguarded.
Fix: omit the `Content-Type:` line when null or blank via
`dev.langchain4j.internal.Utils.isNullOrBlank`, mirroring OkHttp. The
valid-content-type path is unchanged (backward compatible).
Tests: three `MultipartBodyPublisherTest` cases — null and blank (no
`Content-Type:` line) and a valid regression (`Content-Type: audio/wav`
still emitted).
Only the Apache client changes; the JDK client
(`langchain4j-http-client-jdk`) has the identical bug, held for a
follow-up after this merges (probe-first).
Note: Spotless ratchet reindented a few text blocks (CI-required), not
an unrelated change.
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [X] I have added unit and/or integration tests for my change
- [X] The tests cover both positive and negative cases
- [X] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green <!-- N/A — change is confined to
langchain4j-http-client-apache; core built transitively via -am and
passed -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
<!-- N/A — no user-facing API/doc change; internal multipart wire format
-->
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features) <!-- N/A — bug fix, not a big feature -->
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable) <!-- N/A — not applicable -->
<!-- Checklist for adding new maven module: skipped — no new module. -->
<!-- Checklist for adding/changing embedding store integration: skipped
— not an embedding store. -->
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
## Issue
Relates to #5466. That issue is fixed for the **Apache** client in #5467
and explicitly notes that *"The JDK client
(`langchain4j-http-client-jdk`) has the identical bug"*. This PR fixes
the **JDK** client half. No dedicated JDK issue exists, so this
references #5466 rather than closing it — happy to track it under a
separate issue if maintainers prefer.
## Change
`MultipartBodyPublisher.addFile` in `langchain4j-http-client-jdk`
concatenated `"Content-Type: " + file.contentType()` into the part
header unconditionally, so:
- a **null** content type emitted a literal `Content-Type: null` line,
and
- a **blank** content type emitted an empty `Content-Type:` line,
both of which are malformed multipart. This is reachable on a normal
path: `Audio.mimeType()` is null when unset and
`DefaultOpenAiClient.audioTranscription()` forwards `file.mimeType()`
unguarded — and the JDK client is the default HTTP client.
The fix guards the header with `Utils.isNullOrBlank(...)` so the
per-part `Content-Type` line is omitted when the content type is null or
blank, matching the OkHttp client and the accepted Apache fix (#5467).
Behaviour is unchanged when a content type is present.
Added unit tests for the null and blank cases; the existing
`should_build_body_with_file` test already covers the positive
(content-type-present) case.
## General checklist
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and [main](https://github.com/langchain4j/langchain4j) modules, and they
are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
> **Note on testing:** I ran the changed module's unit tests
(`langchain4j-http-client-jdk`, `MultipartBodyPublisherTest`) — 5/5
green — and `spotless:check` passes. The module's `*IT` integration
tests require live HTTP endpoints and were not run. The change is
isolated to `langchain4j-http-client-jdk`, which the core/main modules
do not depend on.
Co-authored-by: Q1Xuan <242799924+Q1Xuan@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bumps
[org.apache.httpcomponents.client5:httpclient5](https://github.com/apache/httpcomponents-client)
from 5.6 to 5.6.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/apache/httpcomponents-client/blob/rel/v5.6.1/RELEASE_NOTES.txt">org.apache.httpcomponents.client5:httpclient5's
changelog</a>.</em></p>
<blockquote>
<h2>Release 5.6.1</h2>
<p>This is a maintenance release disables experimental SCRAM auth scheme
by default and
fixes SCRAM final response handling. The SCRAM auth scheme can be
re-enabled by
choosing a custom auth scheme preference sequence that explicitly
includes SCRAM auth.</p>
<h2>Change Log</h2>
<ul>
<li>
<p>Fix SCRAM final response handling.
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
<li>
<p>Auth challenge parsing code improvement.
Contributed by Oleg Kalnichevski <!-- raw HTML omitted --></p>
</li>
<li>
<p>Add missing Javadoc for ConnectionConfig (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/820">#820</a>).
Contributed by Gary Gregory <!-- raw HTML omitted --></p>
</li>
<li>
<p>Bug fix: Corrected async message exchange cancellation logic in
InternalHttpAsyncExecRuntime.
Contributed by Oleg Kalnichevski <!-- raw HTML omitted --></p>
</li>
<li>
<p>HTTPCLIENT-2417: Honor TlsConfig attachment in async connect path.
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
<li>
<p>HTTPCLIENT-2414: Fix Basic auth cache scoping across path prefixes
(<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/802">#802</a>).
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
<li>
<p>HTTPCLIENT-2415: Normalize CookieOrigin path for cookie matching (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/803">#803</a>).
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
<li>
<p>Bug fix: Corrected sleep time calculation in IdleConnectionEvictor;
use 1 minute sleep
time by default.
Contributed by Oleg Kalnichevski <!-- raw HTML omitted --></p>
</li>
<li>
<p>DefaultManagedHttpClientConnection: Restore original socket timeout.
Contributed by Ryan Schmitt <!-- raw HTML omitted --></p>
</li>
<li>
<p>HTTPCLIENT-2411: Use standard HTTP-date format for synthesized Date
header (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/775">#775</a>).
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
<li>
<p>Fix NPE in connection evictor setup (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/774">#774</a>).
Contributed by Arturo Bernal <!-- raw HTML omitted --></p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4f86ca6a5e"><code>4f86ca6</code></a>
HttpClient 5.6.1 release</li>
<li><a
href="1b2bafe817"><code>1b2bafe</code></a>
Updated release notes for HttpClient 5.6.1 release</li>
<li><a
href="1acf00b879"><code>1acf00b</code></a>
Fix SCRAM final response handling</li>
<li><a
href="49549abca8"><code>49549ab</code></a>
Auth challenge parsing code improvement</li>
<li><a
href="fa6b6d70af"><code>fa6b6d7</code></a>
Add missing Javadoc for ConnectionConfig (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/820">#820</a>)</li>
<li><a
href="3de8ad5e99"><code>3de8ad5</code></a>
Fixed DefaultClientTlsStrategy test failures on MacOS</li>
<li><a
href="c69f38f764"><code>c69f38f</code></a>
Bug-fix: corrects message exchange cancellation logic in
InternalHttpAsyncExe...</li>
<li><a
href="30386d3096"><code>30386d3</code></a>
HTTPCLIENT-2417 Honor TlsConfig attachment in async connect path</li>
<li><a
href="9cc45f6c67"><code>9cc45f6</code></a>
HTTPCLIENT-2414 - Fix Basic auth cache scoping across path prefixes (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/802">#802</a>)</li>
<li><a
href="1e01a487e2"><code>1e01a48</code></a>
HTTPCLIENT-2415: Normalize CookieOrigin path for cookie matching (<a
href="https://redirect.github.com/apache/httpcomponents-client/issues/803">#803</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/apache/httpcomponents-client/compare/rel/v5.6...rel/v5.6.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/langchain4j/langchain4j/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#3775
## Change
<!-- Please describe the changes you made. -->
Simply integrated Apache HttpClient 5 and modified the timeout in the
HttpClientTimeoutIT class within the langchain4j-http-client test
methods to 1 second. Since Apache HttpClient 5's asynchronous timeout
cannot accurately implement a 250-millisecond timeout, the effect can
only be achieved by increasing the timeout duration.
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [x] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
---------
Co-authored-by: Dmytro Liubarskyi <ljubarskij@gmail.com>
## Issue
Closes#4339
## Change
Restore interrupt status by calling `Thread.currentThread().interrupt()`
when catching `InterruptedException`:
- `AbstractInProcessEmbeddingModel.parallelizeEmbedding()`: Separate
`InterruptedException` from `ExecutionException`
- `JdkHttpClient.execute()`: Separate `InterruptedException` from
`IOException`
## General checklist
- [X] There are no breaking changes (API, behaviour)
- [ ] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
<!--
Thank you so much for your contribution!
Please fill in all the sections below.
Please open the PR as a draft initially. Once it is reviewed and
approved, we will ask you to add documentation and examples.
Please note that PRs with breaking changes or without tests will be
rejected.
Please note that PRs will be reviewed based on the priority of the
issues they address.
We ask for your patience. We are doing our best to review your PR as
quickly as possible.
Please refrain from pinging and asking when it will be reviewed. Thank
you for understanding!
-->
## Issue
<!-- Please specify the ID of the issue this PR is addressing. For
example: "Closes #1234" or "Fixes #1234" -->
Closes#2985
## Change
This PR adds OpenAI audio transcription support to langchain4j,
implementing the `/audio/transcriptions` API endpoint. The
implementation follows the existing patterns in the codebase and
integrates cleanly with the HTTP client infrastructure.
### Key Changes
- Added `AudioTranscriptionModel` interface in langchain4j-core with
convenience methods
- Implemented `OpenAiAudioModel` with support for Whisper and GPT-4o
transcription models
- Added multipart/form-data support to HTTP client infrastructure
(`addFile()` method)
- Created `MultipartBodyPublisher` for JDK HTTP client to handle file
uploads
- Implemented audio format detection and binary/base64 data handling
- Added comprehensive test coverage including integration tests
- Updated Azure OpenAI implementation to use new interface
### Sequence Diagram
```mermaid
sequenceDiagram
participant User
participant OpenAiAudioModel
participant OpenAiClient
participant DefaultOpenAiClient
participant JdkHttpClient
participant MultipartBodyPublisher
participant OpenAI API
User->>OpenAiAudioModel: transcribe(AudioTranscriptionRequest)
OpenAiAudioModel->>OpenAiAudioModel: validate(audioRequest)
OpenAiAudioModel->>OpenAiAudioModel: requestBuilder()
OpenAiAudioModel->>OpenAiClient: audioTranscription(OpenAiAudioTranscriptionRequest)
OpenAiClient->>DefaultOpenAiClient: audioTranscription()
DefaultOpenAiClient->>DefaultOpenAiClient: getBinaryDataFromAudio()
DefaultOpenAiClient->>DefaultOpenAiClient: getAudioExtension()
DefaultOpenAiClient->>DefaultOpenAiClient: build HttpRequest with multipart data
DefaultOpenAiClient->>JdkHttpClient: execute(HttpRequest)
JdkHttpClient->>JdkHttpClient: toJdkRequest()
JdkHttpClient->>MultipartBodyPublisher: ofMultipartData()
MultipartBodyPublisher->>MultipartBodyPublisher: addFormField()
MultipartBodyPublisher->>MultipartBodyPublisher: addFile()
MultipartBodyPublisher->>MultipartBodyPublisher: build()
JdkHttpClient->>OpenAI API: POST /audio/transcriptions
OpenAI API-->>JdkHttpClient: OpenAiAudioTranscriptionResponse
JdkHttpClient-->>DefaultOpenAiClient: SuccessfulHttpResponse
DefaultOpenAiClient-->>OpenAiClient: ParsedAndRawResponse
OpenAiClient-->>OpenAiAudioModel: OpenAiAudioTranscriptionResponse
OpenAiAudioModel->>OpenAiAudioModel: AudioTranscriptionResponse.from()
OpenAiAudioModel-->>User: AudioTranscriptionResponse
```
## General checklist
<!-- Please double-check the following points and mark them like this:
[X] -->
- [x] There are no breaking changes (API, behaviour)
- [x] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases
- [ ] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [ ] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
<!-- Before adding documentation and example(s) (below), please wait
until the PR is reviewed and approved. -->
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
## Checklist for adding new maven module
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added my new module in the root `pom.xml` and
`langchain4j-bom/pom.xml`
## Checklist for adding new embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreIT` that extends
from either `EmbeddingStoreIT` or `EmbeddingStoreWithFilteringIT`
- [ ] I have added a `{NameOfIntegration}EmbeddingStoreRemovalIT` that
extends from `EmbeddingStoreWithRemovalIT`
## Checklist for changing existing embedding store integration
<!-- Please double-check the following points and mark them like this:
[X] -->
- [ ] I have manually verified that the
`{NameOfIntegration}EmbeddingStore` works correctly with the data
persisted using the latest released version of LangChain4j
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
## Change
- Added `maven-flatten-plugin` to `langchain4j-parent` and
`langchain4j-bom`
- Removed integration-specific dependencies from `langchain4j-parent`'s
`dependencyManagement` section and moved them to the modules where these
dependencies are used
- Explicitly added missing implicit dependencies
- Removed redundant `<maven.compiler.release>` for cassandra, infinispan
and opensearch modules
- Removed redundant license declarations and outdated properties
## General checklist
- [ ] There are no breaking changes
- [ ] I have added unit and/or integration tests for my change
- [ ] The tests cover both positive and negative cases
- [x] I have manually run all the unit and integration tests in the
module I have added/changed, and they are all green
- [x] I have manually run all the unit and integration tests in the
[core](https://github.com/langchain4j/langchain4j/tree/main/langchain4j-core)
and
[main](https://github.com/langchain4j/langchain4j/tree/main/langchain4j)
modules, and they are all green
- [ ] I have added/updated the
[documentation](https://github.com/langchain4j/langchain4j/tree/main/docs/docs)
- [ ] I have added an example in the [examples
repo](https://github.com/langchain4j/langchain4j-examples) (only for
"big" features)
- [ ] I have added/updated [Spring Boot
starter(s)](https://github.com/langchain4j/langchain4j-spring) (if
applicable)
Dmytro Liubarskyi
Rui Yang