Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

fix: closing a withOptions client closes shared resources

Đang mở
  • Có gì không ổn?
#850 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@abhinavkr26104 đang làm issue này rồi.

Từ ngày 10/8/2026.

  • #851 của @abhinavkr26104 — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, kotlin
Lĩnh vực
api

Hướng nghiên cứu

Bắt đầu với ClientOptions.kt, đặc biệt là việc sao chép của builder ở các dòng 222-228, thiết lập ownership ở 257-259 và logic đóng ở 773-777; sau đó theo dõi withOptions() trong OpenAIClientImpl.kt và OpenAIClientAsyncImpl.kt. Xác minh rằng các client dẫn xuất và client ban đầu vẫn có thể sử dụng được theo cả hai thứ tự đóng đối với các client sync và async, bao gồm cả vòng đời của transport, executor và sleeper.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Description

withOptions() returns a derived client/view, but the derived client shares several resources with the original client and then treats them as independently owned. Closing the derived client can therefore shut down the original client's HTTP transport, streaming executor, and sleeper.

The public API documents withOptions() as returning a view and says that the original service is not modified, so callers reasonably expect the original client to remain usable after closing a short-lived derived client.

Reproduction

A minimal reproduction can use a custom HttpClient whose close() records a flag:

val transport = RecordingHttpClient()
val original =
    ClientOptions.builder()
        .httpClient(transport)
        .apiKey(test)
        .build()
val derived = original.toBuilder().build()

derived.close()

// Expected: transport is still open and original can execute requests.
// Actual: transport.close() has been called, and the original now uses a closed transport.
check(!transport.closed)

The same lifecycle is exposed through the public clients:

OpenAIClient original = OpenAIOkHttpClient.builder().apiKey(test).build();
OpenAIClient derived = original.withOptions(options -> options.baseUrl(https://example.test));
derived.close();

// The original should still be usable, but its shared transport/executor has been closed.
original.models().list();

Code reference

  • openai-java-core/src/main/kotlin/com/openai/core/ClientOptions.kt:222-228 copies originalHttpClient, streamHandlerExecutor, and sleeper into a new builder.
  • openai-java-core/src/main/kotlin/com/openai/core/ClientOptions.kt:257-259 wraps the supplied HTTP client, and the class documentation says the options object owns and closes it.
  • openai-java-core/src/main/kotlin/com/openai/core/ClientOptions.kt:773-777 closes the HTTP client, executor, and sleeper unconditionally.
  • openai-java-core/src/main/kotlin/com/openai/client/OpenAIClientImpl.kt:146-147 and OpenAIClientAsyncImpl.kt:166-167 implement withOptions() by building a new client from clientOptions.toBuilder().
  • openai-java-core/src/main/kotlin/com/openai/client/OpenAIClient.kt:61-66 and OpenAIClientAsync.kt:61-66 document the result as a view whose original service is not modified.

Expected behavior

Closing a derived client should not invalidate the original client or any resources still owned by it. Resource ownership should either be shared through a lifecycle holder/reference count, or derived views should be non-owning and leave shared resources to the original owner.

This should be covered for sync and async clients, including closing the derived client before the original and closing the original before the derived.

Why it matters

This can cause intermittent failures in applications that create per-request clients with withOptions() and close them promptly: later requests through the long-lived original client may fail because the HTTP transport is closed, the streaming executor rejects tasks, or the sleeper is no longer usable. It also makes the documented view semantics unsafe.

Ngôn ngữ chính
Kotlin
Star
1.5k
Fork
268
Merge trung bình
13 giờ 30 phút
Pull request đã merge (30 ngày)
160

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của openai/openai-java

Tất cả issue của openai/openai-java

Issue tương tự

Thêm issue về Kotlin

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.