venkata91 commented on PR #26592: URL: https://github.com/apache/flink/pull/26592#issuecomment-2942995615
**Summary of Local Testing Results for nested projection pushdown Bug**: **Test Setup**: Ran tests locally using FileSystemTableSource with JSON file format. Enabled nested projection pushdown. Set JVM flags in both TaskManager and sql-client to vary BYTE_ARRAY_BASE_OFFSET to simulate different JVM behaviors. **Findings:** **Bug is still real** — just not reproducible locally. Despite correct JVM flag configurations, the issue doesn’t manifest in the local setup. The bug appears only when padding bytes in the byte[] key differ between join sides — highly dependent on JVM internals like version and memory layout. Typically, the padding bytes follow a pattern like [1, 0, 0, ..., 0]. **Other Attempts to Reproduce:** 1. **Custom test data with BINARY(16)**: Keys crafted with mismatched first 8 bytes and matched last 8 bytes. Expected faulty joins due to padding offset misalignment, but HashJoin and shuffle use different hash code paths — didn’t trigger the issue. 2. **Reversed BYTE_ARRAY_BASE_OFFSET (16 vs 24)**: Tried to introduce variability in padding bytes. But offsets 16–24 are mostly just array metadata (length, zeros) — didn’t influence the actual content comparison. **Conclusion**: 1. The issue is highly environment-specific and consistently reproducible only in internal environments. 2. The fix forces consistent computation of BYTE_ARRAY_BASE_OFFSET in TaskManagers, eliminating the JVM-induced inconsistency. 3. Given the low likelihood of regression and the complexity of reproducing the issue locally, proposing to merge this fix without an ITCase test. Thoughts? -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
