rangareddy commented on PR #19485:
URL: https://github.com/apache/hudi/pull/19485#issuecomment-5165664578
Validation update: I have now run
`testUpsertsContinuousModeWithMultipleWritersForConflicts` locally, which I
could not do when I opened this. **It passes with these changes** — four runs
over both `HoodieTableType` parameters, 8 green executions at ~88s each:
```
run 1: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
run 2: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
run 3: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
run 4: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
```
Full `TestHoodieDeltaStreamerWithMultiWriter`: 5 tests, 157.6s, green.
`checkstyle:check` and `apache-rat:check` clean. The PR description is updated
accordingly.
No flake reproduced in those runs, so this change is not masking one. That
also means it is not evidence the flake is gone — four local runs on one
machine say little about CI, where the original report came from a much busier
executor. The claim in this PR is unchanged: it does not fix the flake, it
makes the next occurrence name the assertion that was still failing.
### Two environment traps worth recording, since anyone reproducing this
will hit them
**1. Switching Spark profiles without `clean` leaves bytecode bound to the
wrong Spark API.** The test was failing for me with:
```
NoClassDefFoundError:
org/apache/spark/sql/internal/SQLConf$LegacyBehaviorPolicy$
at
org.apache.spark.sql.avro.AvroDeserializer.<init>(AvroDeserializer.scala:74)
at org.apache.spark.sql.avro.HoodieSpark3_5AvroDeserializer.<init>
```
`hudi-spark3-common` vendors `AvroDeserializer`, and as its own comment
explains, `LegacyBehaviorPolicy` is nested in `SQLConf` on Spark 3.3/3.4 but a
top-level `org.apache.spark.sql.internal.LegacyBehaviorPolicy` on 3.5 — it
relies on two wildcard imports so the same source compiles either way. Which
one it binds to is therefore fixed at **compile** time.
My local `hudi-spark3-common` had been built earlier under a 3.3/3.4
profile. Re-running `mvn install -Dspark3.5` did **not** fix it: the jar was
repackaged but the Scala classes were not recompiled, so it still emitted
```
getstatic org/apache/spark/sql/internal/SQLConf$LegacyBehaviorPolicy$.MODULE$
```
against a Spark 3.5.5 runtime where `spark-catalyst` has no nested
`LegacyBehaviorPolicy` at all (it lives in `spark-sql-api` as a top-level
class). Only `mvn clean install -Dspark3.5 -Dscala-2.12` rebound it to
`internal/LegacyBehaviorPolicy$`. Worth knowing that this silent-until-runtime
mismatch is what a stale incremental build looks like here.
**2. The test needs Docker, and Ryuk can block it.**
`HoodieDeltaStreamerTestBase.initClass` starts a Kafka container via
testcontainers, and it aborted in `@BeforeAll` with:
```
IllegalStateException: Could not connect to Ryuk at localhost:50073
at org.testcontainers.utility.RyukResourceReaper.maybeStart
at
org.apache.hudi.utilities.testutils.KafkaTestUtils.setup(KafkaTestUtils.java:55)
```
No stale Ryuk container existed; the reaper simply failed to bind.
`TESTCONTAINERS_RYUK_DISABLED=true` gets past it — Ryuk only reaps leftover
containers, so the cost is manual cleanup.
For anyone reproducing, the working invocation was:
```bash
mvn clean install -DskipTests -Dspark3.5 -Dscala-2.12 -pl hudi-utilities -am
TESTCONTAINERS_RYUK_DISABLED=true mvn test -pl hudi-utilities -Dspark3.5
-Dscala-2.12 -Punit-tests \
-Dtest='TestHoodieDeltaStreamerWithMultiWriter#testUpsertsContinuousModeWithMultipleWritersForConflicts'
```
--
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]
