Skip to content

[not to land] Add Android ECH Testcontainers workflow - #9652

Closed
yschimke wants to merge 1 commit into
lysine-dev:mainfrom
yschimke:agent/android-ech-testcontainers
Closed

[not to land] Add Android ECH Testcontainers workflow#9652
yschimke wants to merge 1 commit into
lysine-dev:mainfrom
yschimke:agent/android-ech-testcontainers

Conversation

@yschimke

Copy link
Copy Markdown
Collaborator

100% vibe coded - for discussion only

@yschimke
yschimke force-pushed the agent/android-ech-testcontainers branch from 18288b8 to 6a87a3a Compare August 11, 2026 07:52
@yschimke yschimke added the containers Container tests (Docker) label Aug 11, 2026
@yschimke

Copy link
Copy Markdown
Collaborator Author

Failures are expected until ECH retries lands

okhttp.android.test.EncryptedClientHelloTest > rejectedConfigIsRetriedWithServerConfig[emulator-5554 - 17] FAILED
android.net.ssl.EchConfigMismatchException: The ECH configuration has been rejected by the server
at com.android.org.conscrypt.Platform.wrapEchRejectedException(Platform.java:569)

okhttp.android.test.EncryptedClientHelloTest > rejectedConfigWithoutServerConfigIsRetriedWithoutEch[emulator-5554 - 17] FAILED
android.net.ssl.EchConfigMismatchException: The ECH configuration has been rejected by the server
at com.android.org.conscrypt.Platform.wrapEchRejectedException(Platform.java:569)
Tests on emulator-5554 - 17 failed: There was 2 failure(s).
Finished 3 tests on emulator-5554 - 17

@swankjesse

Copy link
Copy Markdown
Collaborator

I am not a big fan of using containers in OkHttp’s test suite in general, because the tests are slower & flakier than MockWebServer tests.

We're in a difficult period for open source. Published libraries are frequently compromised, cascading through publish actions to own developers machines and CI environments. Taking on more transitive deps increases that risk. To be honest I'd rather eject some of our existing dependencies than add more.

And I'm further not confident that transitive dependencies will continue to be stable and reliable, in a way I considered them to be last year. Our industry is currently in a mood to prefer velocity over quality. Probably great for certain use cases but not a good fit for a boring foundational library like ours.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

containers Container tests (Docker)

Development

Successfully merging this pull request may close these issues.

2 participants