voonhous commented on code in PR #19642:
URL: https://github.com/apache/hudi/pull/19642#discussion_r3794804465
##########
release/release_guide.md:
##########
@@ -290,6 +290,31 @@ Here is how to go about a bug fix release.
- Go to apache/hudi repo locally and pull this branch. Here after you can work
on this branch and push to origin when need be.
- Do not forget to set the env variables from above section.
+## hudi-trino Trino pin-back
+
+On master hudi-trino tracks `trinodb/trino` master at the commit in
`trino.sha`, whose `trino.version` is a
+`-SNAPSHOT` that resolves from nowhere but a local build. A release must
depend on a released Trino, and the pin-back
+must land on the release branch before the source release is generated (see
"Build a release candidate", the Generate
+Source Release step) -- otherwise the voted tarball ships a `-SNAPSHOT` Trino
pin that cannot be built from Central.
+
+1. Wait for the latest released Trino `NNN` to be available on Maven Central.
+2. In a `trinodb/trino` checkout, find the tagged commit: `TAG_SHA=$(git
rev-list -n1 NNN)`.
+3. If the pin is behind the tag, advance master's pin to `TAG_SHA` first by
dispatching the
+ `Hudi Trino SPI Compatibility` workflow with `trino_ref=NNN` (it then
verifies and pins exactly that tag rather
+ than master HEAD) and merging the pin PR a committer opens from the pushed
`bot/trino-pin` branch. If the pin is ahead of the tag, enumerate the
adaptations that would be lost with
+ `git log NNN..<pin> -- core/trino-spi lib/trino-filesystem
lib/trino-filesystem-manager lib/trino-hdfs`
+ and revert them forward on the release branch only, never on master.
+4. On the release branch set `trino.version=NNN`, `trino.sha=TAG_SHA` and
`trino.e2e.version=NNN` in the root
+ pom, the `<parent>` version in `docker/trino/shim/pom.xml`, and the
`docker/trino` defaults
+ (`TRINO_VERSION` in `build_image.sh`, `ARG TRINO_VERSION` in `Dockerfile`).
Re-check SPI-surface-coupled
Review Comment:
Dropped in b92f718be3f5 -- the step now names only the root pom properties,
the shim parent, and the Dockerfile `ARG` default (with a note that
`build_image.sh` reads `trino.e2e.version` from the pom).
##########
hudi-trino/src/main/java/io/trino/plugin/hudi/HudiSplitSource.java:
##########
@@ -188,7 +168,13 @@ public void close()
@Override
public boolean isFinished()
{
- return splitLoaderFuture.isDone() && queue.isFinished();
+ return finished.get() || (splitLoaderFuture.isDone() &&
queue.isFinished());
Review Comment:
Confirmed against the loader: `whenAllComplete` ran `asyncQueue.finish()`
without consulting the futures, unordered against `addExceptionCallback`. Fixed
in b92f718be3f5: the combiner now drains each future with `Futures.getDone` and
routes failures through the error listener before finishing the queue (the
listener is idempotent, so double reporting with the fail-fast callback is
harmless). Covered in the new `TestHudiSplitSource` at the source level -- a
loader failure blocks `isFinished` and surfaces on the next batch; the Guava
callback race itself is not deterministically reproducible, but with the
combiner reporting first, correctness no longer depends on that ordering.
--
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]
