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

Flaky: AuthProxyHeadersTest.rtm intermittently sees 3 proxy tunnels, expects 2

Đã đóng
  • Có gì không ổn?
#1,630 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đá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
Sôi nổi
Công nghệ
java
Lĩnh vực
networking, testing

Hướng nghiên cứu

Bắt đầu tại slack-api-client/src/test/java/test_with_remote_apis/AuthProxyHeadersTest.java, tập trung vào rtm(), số lượng ConnectHandler được nhúng của Jetty và assertion của scim() tương ứng. Xem lại thay đổi rtmConnect(..., false) hiện có và lần theo CONNECT tunnel dư thừa xuất hiện không thường xuyên. Công việc hoàn tất khi test có tính tất định nhưng vẫn xác minh hành vi xác thực proxy.

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

Mô tả

auto-triage-stale

Summary

test_with_remote_apis.AuthProxyHeadersTest.rtm is flaky. It asserts the embedded proxy handled exactly 2 connections:

assertThat(callCount.get(), is(2));

but intermittently observes 3 (Expected: is <2> ... but: was <3>), failing the build. The test's callCount is incremented by the embedded Jetty ConnectHandler on every non-407 CONNECT tunnel, so a 3 means an extra tunnel was opened through the proxy during the RTM flow.

Status of the attempted fix (this is the point of the issue)

A change on the api branch switched the call to rtmConnect(rtmBotToken, false) — dropping the fullUserInfoRequired users.info call on the theory that it was the extra HTTPS round-trip inflating the tunnel count to 3. See the change on api:

// two connections (rtm.connect + websocket), otherwise a third tunnel can be opened
try (RTMClient rtm = slack.rtmConnect(rtmBotToken, false)) {

That change does not make the test deterministic. A build that includes the false change on api still failed rtm with was <3> at the is(2) assertion. So dropping users.info was, at most, a partial mitigation — the extra CONNECT tunnel has another source (a WebSocket reconnect, a keep-alive revalidation opening a fresh tunnel, or similar timing). Whether the change lowers the flake rate is unconfirmed; it does not eliminate the flake.

Repro / evidence

Intermittent — the same test passes on other builds, and fails on others with the false change present. Confirmed by the fact that the assertion still hits was <3> on api, which carries the change.

Possible directions (not yet chosen)

  1. Assert a bounded range instead of an exact count — the test's real intent is "the proxy was used with the auth header," not "exactly N tunnels." A tolerant assertion (e.g. >= 2, or anyOf(is(2), is(3))) would kill the flake without weakening what's verified (a 407 or a leaked connection would still show up as a wrong count). Follows the same pattern already used in the sibling scim() test in this file (assertTrue(callCount.get() >= 1)).
  2. Find and eliminate the extra tunnel — trace whether the RTM WebSocket connect opens a second CONNECT under the proxy (reconnect / pooled-connection revalidation) and make the count deterministic. Harder; needs the proxy's per-CONNECT logging enabled to see the real tunnel sequence.

Filing so the flake is on the record and the false change on api isn't mistaken for a settled fix.

Ngôn ngữ chính
Java
Star
602
Fork
235
Merge trung bình
2 ngày 1 giờ
Pull request đã merge (30 ngày)
7

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

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 slackapi/java-slack-sdk

Tất cả issue của slackapi/java-slack-sdk

Issue tương tự

Thêm issue về Java

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.