david-streamlio opened a new issue, #83:
URL: https://github.com/apache/pulsar-connectors/issues/83
## Description
`PulsarSchemaHistoryTest` (in `debezium/core`) intermittently fails in
`setup()`:
```
org.apache.pulsar.io.debezium.PulsarSchemaHistoryTest > setup FAILED
org.apache.pulsar.client.admin.PulsarAdminException$NotFoundException:
Tenant does not exist
javax.ws.rs.NotFoundException: HTTP 404 {"reason":"Tenant does not
exist"}
```
Observed on an unrelated PR (#79, a DynamoDB client-construction fix):
https://github.com/apache/pulsar-connectors/actions/runs/29055562433 — that
PR's own tests all passed; only this one failed, so it fails PRs that have
nothing to do with it.
## Root cause
`setup()` creates a namespace as soon as the container reports ready:
```java
pulsarContainer = new PulsarContainer(DockerImageName.parse(PULSAR_IMAGE));
pulsarContainer.start();
...
admin.namespaces().createNamespace("public/my-ns"); // <-- may race
```
The broker creates the `public` tenant **asynchronously** during bootstrap.
`PulsarContainer`'s wait strategy returns once the broker's port and startup
log are up, which can precede tenant creation. When it does,
`createNamespace("public/my-ns")` gets a 404 and the whole class fails at
`@BeforeMethod`.
Because `setup()` is a `@BeforeMethod`, one lost race takes down every test
in the class.
## Note on reproduction
This does **not** reproduce locally on a warm machine — probing
`admin.tenants().getTenants()` immediately after `start()` returns `[public,
pulsar]` every time, i.e. the tenant is already there before the first call.
The window only opens under CI's slower, contended runners. That is
characteristic of this class of flake and is why it has been rare.
## Fix
Wait for the `public` tenant to exist before creating the namespace, rather
than assuming container-ready implies tenant-ready.
This is the third timing-flake class found in this repo today, after the
file connector's queue hand-off races (#12 / #41) and the InfluxDB sink's
fixed-`Thread.sleep` assertion (#53 / #73). The pattern is the same each time:
a test assumes an asynchronous step has completed because a synchronous one has.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
