Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Flaky test: HttpTransportTests.testAccessTokenAuth / testBearerTokenAuth bind a random fixed port and fail with FatalStartupException

Aperta Adatta ai principianti
  • Qualcosa non va?
#3,076 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
92/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
testing

Direzione di ricerca

Apri client-v2/src/test/java/com/clickhouse/client/HttpTransportTests.java e ispeziona testBearerTokenAuth intorno alla riga 1307 e testAccessTokenAuth intorno alla riga 1385. Confronta la loro configurazione WireMock con gli altri utilizzi di .dynamicPort() nel file, quindi esegui il comando Maven dell’issue per i test di autenticazione. Il lavoro è completato quando entrambi i test ottengono una porta dinamica libera e superano l’esecuzione senza errori di bind in condizioni di contesa sulla porta.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug client-api-v2 test

Description

HttpTransportTests.testAccessTokenAuth and HttpTransportTests.testBearerTokenAuth
(module client-v2) start their WireMock server on a randomly chosen fixed port:

int randomPort = ThreadLocalRandom.current().nextInt(3000, 65535);
WireMockServer mockServer = new WireMockServer(WireMockConfiguration
        .options().port(randomPort).notifier(new ConsoleNotifier(false)));
mockServer.start();

client-v2/src/test/java/com/clickhouse/client/HttpTransportTests.java:1307 (testBearerTokenAuth)
and :1385 (testAccessTokenAuth).

If that port is already taken, mockServer.start() throws immediately and the test fails.
There is no retry and no fallback. The chosen range (3000-65535) overlaps the Linux
ephemeral port range (/proc/sys/net/ipv4/ip_local_port_range = 32768-60999 on the CI
runners), so any outbound socket held by a concurrently running test, by Maven, or by
another job on the same runner can take the port.

Every other WireMock server in the same file already uses .dynamicPort() (about 20
occurrences, e.g. lines 895, 1465, 1854). Only these two tests use the fixed-port form.

Steps to reproduce
  1. Occupy an arbitrary subset of TCP ports in 3000-65535 on the machine (this simulates a
    loaded CI runner). For the numbers below, 29768 ports (3000-32767, 47.6% of the range)
    were held by a helper process; the ephemeral range was left free so outbound
    connections still worked.
  2. Run the test repeatedly:
    mvn -B -pl client-v2 -DskipUTs=true -Dit.test=HttpTransportTests#testAccessTokenAuth -Dfailsafe.failIfNoSpecifiedTests=false -DfailIfNoTests=false verify
  3. The test fails on roughly the fraction of the range that is occupied.

Observed: 4 failures out of 12 runs (33%, expected ~48%), each with the same signature
as CI but a different port each time:

run 1: PASS
run 2: FAIL -> Failed to bind to /0.0.0.0:10117
run 3: FAIL -> Failed to bind to /0.0.0.0:15282
run 4: PASS
run 5: FAIL -> Failed to bind to /0.0.0.0:18977
run 6..9: PASS
run 10: FAIL -> Failed to bind to /0.0.0.0:14457
run 11..12: PASS

Contrast: HttpTransportTests#testSessionSettingsClientAndOperationLevels, which uses
.dynamicPort(), passed 6/6 under exactly the same port contention.

Error Log or Exception StackTrace

Verbatim from CI (amazon JDK 17 / "Test all modules",
https://github.com/ClickHouse/clickhouse-java/actions/runs/32807717786/job/97681145686):

[ERROR] com.clickhouse.client.HttpTransportTests.testAccessTokenAuth -- Time elapsed: 0.005 s <<< FAILURE!
com.github.tomakehurst.wiremock.common.FatalStartupException: java.io.IOException: Failed to bind to /0.0.0.0:32783
[ERROR]   HttpTransportTests.testAccessTokenAuth:1388 » FatalStartup ... Failed to bind to /0.0.0.0:32783
[ERROR] Tests run: 897, Failures: 1, Errors: 0, Skipped: 3

Note 32783 is inside the OS ephemeral range. The other 34 legs of the same matrix passed
on the same commit, and the change under test touched only client-v2 metadata handling -
nothing in the auth path - so the failure is not attributable to the code under test.

Expected Behaviour

The test binds a free port and never fails because of port allocation. The Client.Builder
already receives the port from mockServer.port() after start, so nothing needs the port
value in advance.

Code Example

Suggested fix - use the same form as the rest of the file, at both sites:

WireMockServer mockServer = new WireMockServer(WireMockConfiguration
        .options().dynamicPort().notifier(new ConsoleNotifier(false)));
mockServer.start();

.dynamicPort() binds port 0, so the kernel picks a port that is guaranteed free, and
mockServer.port() (already used throughout both tests) returns the actual port. The
randomPort local becomes unused and can be dropped, together with the now-unneeded
ThreadLocalRandom usage if no other test needs it.

Please do not fix this with a retry loop or a narrower random range - both leave the race
in place. There is no product-code race here; the defect is entirely in the test fixture.

Configuration
Environment
  • Cloud
  • Client version: main @ 667cbe90b
  • Language version: OpenJDK 17.0.18
  • OS: Ubuntu 24.04 (container), also seen on the amazon JDK 17 CI runner
ClickHouse Server
  • ClickHouse Server version: not relevant - the test uses a mocked WireMock server and
    returns early when isCloud().

Found by our PR monitor: the failure was seen on unrelated PRs whose changes do not touch
the auth path, and it is already tracked internally as a known non-routing flake. Verified
here by reproducing the bind failure locally under port contention, not by inspection only.

Lingua principale
Java
Stelle
1.6k
Fork
638
Merge medio
2g 14h
PR unite (30g)
44

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ClickHouse/clickhouse-java

Tutte le issue di ClickHouse/clickhouse-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.