Thanks for working on this. I reviewed the latest head from scratch and checked the exact binary-payload append path that runs when stain-trace sampling records another stage hop.

What this PR solves

• User pain: on JDK 8, StainTracePayload.append(...) can hit NoSuchMethodError because the compiled call targets the JDK 9+ covariant ByteBuffer.position(int) signature instead of the JDK 8 Buffer.position(int) signature.
• Fix approach: cast the wrapped buffer to Buffer before calling position(int), so the call binds to the JDK 8-compatible superclass method.
• One-line summary: this is a precise compatibility fix on the real payload-append hot path, and I did not find a new source-level blocker.

Runtime path I checked

sampled row trace path
  -> StainTracePayload.append(...) [81-101]
      -> validate payload
      -> expand byte array
      -> move write cursor to old payload length
      -> append stage code / task ID / timestamp
      -> update entry count

Review result

• StainTracePayload.java:90-100 is exactly the right place to fix this.
• The new cast at StainTracePayload.java:92-96 is minimal and targeted: it preserves the existing binary layout while avoiding the JDK 8 linkage problem.
• I did not see a reopened compatibility or payload-corruption risk from this change.

Tests / CI

• The code change is very small and the compatibility rationale is clear from the in-code comment.
• The current apache-side Build check is red, but the corresponding fork Actions run I inspected is still in progress and has not yet produced a clean final PR-specific failure diagnosis. So I am not treating that red badge as source evidence against this fix.

Conclusion: can merge after fixes

1. Blocking items

• No source-level blocker from my side on the latest head.
• Please make sure the branch ends up with one valid CI result before merge, because the current public Build badge is not a trustworthy final signal yet.

2. Suggested non-blocking follow-up

• None from my side on this code path.

From the code-review side, the JDK 8 compatibility fix itself looks good.

Thanks for the update. I re-checked the latest head from scratch, including the original JDK 8 compatibility fix and the new workflow adjustment.

What this PR fixes:

• User pain: StainTracePayload.append(...) can hit NoSuchMethodError on JDK 8.
• Fix approach: bind the append path to the JDK 8-compatible Buffer.position(int) call; the latest head also increases the Kudu E2E workflow timeout to match real template fan-out.
• One-line summary: the code fix still looks correct, and the newest workflow delta is aligned with the CI symptom rather than masking a code problem.

Runtime path re-checked:

StainTracePayload.append(...)
  -> move buffer cursor
  -> append stage/task/timestamp bytes

Findings:

• No blocking source-level issue on the current head.
• The production compatibility fix remains correct on StainTracePayload.java:90-96.
• The latest delta in .github/workflows/backend.yml:1240 simply increases the Kudu E2E timeout from 60 to 90 minutes, which matches the expanded template load.

CI:

• statusCheckRollup still shows an old failing Build check-run, but head_sha=e6b2ad3... maps to the latest Apache workflow runs and both are successful.

Conclusion: can merge

1. Blocking items

• None.

2. Suggested follow-up

• None.

Overall, this is mergeable.

Thanks for the update. I re-reviewed the latest head from scratch, including the original JDK 8 compatibility fix and the new Pulsar E2E / workflow follow-up commits.

What this PR solves

• User pain: once stain-trace sampling hits, StainTracePayload.append(...) runs on the real source/transform/sink trace path. On JDK 8, a direct ByteBuffer.position(int) call can link to the JDK 9+ covariant signature and fail at runtime with NoSuchMethodError.
• Fix approach: the latest head binds that cursor move to Buffer.position(int) via ((Buffer) buffer).position(...), while keeping the payload binary layout unchanged.
• One-line summary: this is still a precise compatibility fix on the real hot path, and I did not find a new source-level blocker in the latest head.

Runtime path I checked

sampled row trace path
  -> SeaTunnelSourceCollector.tryStainTrace(...) [SeaTunnelSourceCollector.java:342-369]
      -> StainTracePayload.init(...)
      -> StainTracePayload.append(...) [StainTracePayload.java:81-101]

row continues through later stages
  -> StainTraceUtils.tryAppendPayload(...) [StainTraceUtils.java:72-91]
      -> StainTracePayload.append(...) again

Review result

• StainTracePayload.java:90-96 is exactly the right place to fix the JDK 8 linkage issue.
• The Buffer cast keeps the on-wire payload format unchanged, so I do not see a serialization or compatibility regression here.
• The new Pulsar E2E helper and test updates look structurally stable as well: no Thread.sleep, no fixed-port assumptions, and the image pre-pull path has an explicit timeout.

CI

• Build is still running on the latest head at the time of this review, so I am not treating CI as a negative code signal right now.

Conclusion: can merge

1. Blocking items

• None from my side on the current source changes.

2. Suggested follow-up

• None.

From the code-review side, this latest head looks good to merge once the running CI finishes cleanly.