DEV Community: Divyansh Kumar

Why Your Testcontainers Check Is Flaky: The Quarkus Port 9000 Trap

Divyansh Kumar — Wed, 07 Oct 2026 14:53:58 +0000

We've all seen integration tests that fail randomly in CI. You run them on your laptop five times in a row, and they pass cleanly every single time without a hiccup. Then you push your commit, and GitHub Actions blows up during initialization with a completely unexpected connection drop. You hit retry. It goes green. It's deeply frustrating.

Drafted with AI assistance from my notes and code, then reviewed and edited by me.

I ran into this exact headache while debugging JsonSchemaRecordValidationIT in the Kroxylicious open source project. Our test suite spins up an Apicurio Registry container via Testcontainers, registers a JSON schema in @BeforeAll, and runs record validation against Kafka.

Locally, my test passed instantly. In CI, builds broke intermittently during initialization. The socket died.

java.lang.RuntimeException: could not close the reader
    at io.kiota.serialization.json.JsonParseNodeFactory.getParseNode(...)
    at io.apicurio.registry.rest.client.groups.item.artifacts.ArtifactsRequestBuilder.post(...)
    at io.kroxylicious.it.filter.validation.JsonSchemaRecordValidationIT.init(...)
Caused by: java.io.IOException: closed
Caused by: java.io.IOException: fixed content-length: 429, bytes received: 0
Caused by: java.io.EOFException: EOF reached while reading

The error felt bizarre. Kiota expected 429 bytes back from the registry, but received zero bytes before the socket slammed shut. Why would an HTTP server drop an incoming connection right after booting?

The Deceptive Wait Strategy

I looked at RecordSchemaValidationBaseIT. Our test used a standard HTTP wait strategy on port 8080:

protected static GenericContainer<?> startRegistryContainer() {
    return new GenericContainer<>(dockerImageName)
            .withExposedPorts(8080)
            .waitingFor(Wait.forHttp("/apis/registry/v3/system/info").forStatusCode(200));
}

On paper, that looks completely sound. Testcontainers pings /apis/registry/v3/system/info until it gets an HTTP 200 response, flags the container as healthy, and hands off control to JUnit. Our code then immediately calls client.groups().byGroupId("default").artifacts().post(...).

If the endpoint returns 200, why did our requests crash?

The Startup Race in Quarkus

Here's what I discovered under the hood. Apicurio Registry 3 runs on Quarkus. When Quarkus boots, Netty binds port 8080 right away. Any endpoint that serves static build metadata straight from memory, like /system/info, starts returning 200 in a fraction of a second.

Meanwhile, the actual database engine is still initializing on a background thread:

INFO [io.quarkus.bootstrap.runner.Timing] Listening on: http://0.0.0.0:8080. Management interface listening on http://0.0.0.0:9000.
INFO [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] Acquiring database initialization lock...
INFO [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] Database not initialized.
INFO [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] Initializing the Apicurio Registry database...
INFO [io.apicurio.registry.storage.impl.sql.AbstractSqlRegistryStorage] Database initialization lock released.

Port 8080 accepts traffic while AbstractSqlRegistryStorage is still running schema migrations on H2.

On my workstation, the database was ready before Testcontainers even sent its first ping. But on a heavily loaded CI runner with constrained CPU, the timing inverted. Testcontainers saw /system/info return 200, thought everything was ready, and triggered our test. Because the HTTP server bound port 8080 almost immediately upon process launch, polling a static system information endpoint gave Testcontainers the false impression that the entire containerized application was completely healthy and prepared to process incoming write operations. Whenever our test runner tried to connect while the internal schema tables were still locked by the migration worker, the Quarkus runtime simply reset the underlying TCP connection without transmitting any bytes back to the waiting Kiota client. That produced the zero-byte EOFException.

Keith Wall, a maintainer on the repo, caught this in issue #5031: "We currently probe /apis/registry/v3/system/info as an indication of readiness. I wonder if this is sufficient?"

It wasn't. A metadata endpoint isn't a readiness probe.

The Fix: Quarkus Management Port 9000

In Quarkus and SmallRye Health, readiness checks don't live on the application port. In Apicurio Registry 3.x, they live on port 9000.

The /health/ready probe on port 9000 queries the Agroal datasource and storage subsystem directly. If database locks or migrations are running, it returns HTTP 503. It returns 200 only when the storage engine can safely accept writes.

I updated RecordSchemaValidationBaseIT to expose port 9000 and pointed the wait strategy to /health/ready:

protected static final int CONTAINER_PORT = 8080;
protected static final int MANAGEMENT_PORT = 9000;

protected static GenericContainer<?> startRegistryContainer() {
    return new GenericContainer<>(dockerImageName)
            .withExposedPorts(CONTAINER_PORT, MANAGEMENT_PORT)
            .waitingFor(Wait.forHttp("/health/ready").forPort(MANAGEMENT_PORT).forStatusCode(200));
}

Our client still talks to port 8080, but Testcontainers won't let our tests run until port 9000 confirms the database is completely ready.

The flakiness disappeared completely. It worked cleanly.

What to Remember

Don't use static metadata endpoints for container readiness. If an app boots its web server before its database or cache is ready, polling an info URL creates a race condition. Always find the framework's dedicated readiness probe, and check if it lives on a separate management port.

What Testing a Real App Taught Me About Building One

Divyansh Kumar — Sun, 26 Oct 2025 18:15:56 +0000

When I joined Stapubox as a Backend + QA Intern, I thought testing would be the “less exciting” part of the journey.
But I was wrong.

Within the first week, I realized testing isn’t about clicking buttons or breaking things—it’s about understanding how real users think. And that changed the way I look at building products forever.

📖 My Story

Since this was my first experience in QA, I honestly didn’t know where to start.

A senior teammate gave me a simple but powerful suggestion:

“Before you think like a developer, think like a user. Do a bit of monkey testing first.”

At first, it sounded funny. But when I started exploring the app like a curious user—signing up, creating a profile, testing chats, checking recommendations—I began noticing small details I would’ve completely ignored as a developer.

Tiny loading delays.
A misplaced button on the onboarding screen.
A chat message that didn’t update in real-time unless I refreshed.

Individually, they seemed minor. But together, they told a bigger story about user experience.

That’s when it hit me—every tiny inconsistency matters because that’s exactly what a user notices first.

By the second week, I wasn’t just finding bugs anymore.
I was understanding why they happened—and more importantly, how to prevent them while building.

💡 What I learned?

Testing taught me lessons no coding tutorial ever could:

Empathy beats logic. You can’t build something great unless you understand how it feels to use it.
Small details aren’t small. A one-second delay or an unhandled state can define how users perceive your entire product.
QA makes you a sharper developer. It forces you to think beyond “does this code work?” to “does this experience make sense?”

Now, whenever I write backend logic, I automatically imagine how a user will interact with that flow on the front end.
And that mindset shift alone has been priceless.

🤝 Over to you!

I used to think testing was the final step in development.
Now, I see it as the foundation of building something truly meaningful.

If you’re a developer—especially early in your journey—I’d love to hear this from you:
👉 How do you make sure your code feels human to the end user?

Let’s share stories, not just syntax. 👇

Stop Shipping Broken .env Files — Meet env-check-ts

Divyansh Kumar — Mon, 07 Jul 2025 05:15:02 +0000

Have you ever deployed your Node.js app, only to see it crash due to a missing or incorrect environment variable?

If yes — you’re not alone.

Environment variables (.env files) are essential for configuring secrets, ports, database URLs, and more — but they’re also fragile and invisible. A single missing or mistyped key can break your entire app in production, CI/CD, or even onboarding new teammates.

That’s exactly the kind of problem I wanted to solve when I created:

env-check-ts

A simple, TypeScript-powered CLI that validates your .env file against a schema and even auto-generates .env.example.

🤷‍♂️The Problem We Often Ignore

Let’s say you’ve got a .env like this:

NODE_ENV=prod
PORT=3000
DATABASE_URL=https://secure-db.com

What if:

NODE_ENV was expected to be "production", not "prod"?
PORT was accidentally deleted?
You forgot to include DATABASE_URL in .env.example?

These bugs don’t get caught until runtime... and by then it’s too late.

🧪The Solution — env-check-ts

env-check-ts solves this with schema validation, powered by Zod. It ensures your .env is:

✅ Present

✅ Complete

✅ Valid by type and value

You can also auto-generate a neat .env.example based on your schema.

🧑‍💻 Try it Now

npm install -g env-check-ts

or use via:

npx env-check-ts validate

Full docs + GitHub: Here

🤔Why I Built This

As a developer working on open-source and team projects, I faced recurring issues:

CI/CD failing due to missing envs
Confusion over .env files in onboarding
Forgetting to update .env.example

I wanted something:

Simple and Type-safe
And powered by a schema — not just regex

So env-check-ts was born. It’s lightweight, zero-config, and developer-first.

🔮What's Next?

I'm actively improving this tool. Upcoming features:

Support for .env.production, .env.test, etc.
Ability to redact secrets when generating .env.example
VS Code extension for inline validation
Auto-run as part of CI/CD pipelines

Have suggestions or ideas? I’d love your feedback!

🫡Final Words

If this tool helped you or your team:

⭐️ Give it a star on GitHub

🗣 Share it with a dev friend or a crazy techy

📥 DM or comment — I'd love to hear your thoughts!

Thanks for reading 🙌
Built with ❤️ by Divyansh Kumar