alamb commented on code in PR #16662:
URL: https://github.com/apache/datafusion/pull/16662#discussion_r2189820163
##########
datafusion/proto/tests/cases/roundtrip_physical_plan.rs:
##########
@@ -1736,3 +1737,55 @@ async fn roundtrip_physical_plan_node() {
let _ = plan.execute(0, ctx.task_ctx()).unwrap();
}
+
+#[tokio::test]
+async fn test_tpch_part_in_list_query_with_real_parquet_data() -> Result<()> {
+ // Test the specific query: SELECT p_size FROM part WHERE p_size IN (14,
6, 5, 31)
+ //
+ // NOTE: This test uses a minimal subset of TPC-H part.parquet data
(tpch_part_small.parquet)
+ // which contains only 20 rows with p_size values in [14, 6, 5, 31] to
reproduce the bug.
+ // Using alltypes_plain.parquet does NOT reproduce the issue, suggesting
the bug
+ // is specific to certain characteristics of TPC-H parquet files or their
schema.
+
+ use datafusion_common::test_util::datafusion_test_data;
+
+ let ctx = SessionContext::new();
+
+ // Register the TPC-H part table using the local test data
+ let test_data = datafusion_test_data();
+ let table_sql = format!(
+ "CREATE EXTERNAL TABLE part STORED AS PARQUET LOCATION
'{}/tpch_part_small.parquet'",
+ test_data
+ );
+ ctx.sql(&table_sql).await.map_err(|e| {
+ DataFusionError::External(format!("Failed to create part table: {}",
e).into())
+ })?;
+
+ // Test the exact problematic query
+ let sql = "SELECT p_size FROM part WHERE p_size IN (14, 6, 5, 31)";
+
+ let logical_plan = ctx.sql(sql).await?.into_unoptimized_plan();
+ let optimized_plan = ctx.state().optimize(&logical_plan)?;
+ let physical_plan =
ctx.state().create_physical_plan(&optimized_plan).await?;
+
+ // Serialize the physical plan - bug may happen here already but not
necessarily manifests
+ let codec = DefaultPhysicalExtensionCodec {};
+ let proto =
PhysicalPlanNode::try_from_physical_plan(physical_plan.clone(), &codec)?;
+
+ // Deserialize the physical plan - this is where the bug occurs
+ let result = proto.try_into_physical_plan(&ctx,
ctx.runtime_env().as_ref(), &codec);
+
+ // BUG: Assert that deserialization fails with the expected error
+ // There won't be an error if the bug is fixed
+ let err =
+ result.expect_err("Expected deserialization to fail due to type
mismatch bug");
+ assert!(
+ err.to_string().contains("inlist should be same")
+ && err.to_string().contains("Int64")
+ && err.to_string().contains("Int32"),
+ "Expected type mismatch error with Int64/Int32, got: {}",
+ err
+ );
Review Comment:
I agree it would be better to mark this test as `#[ignore]` as that follows
the patterns of the rest of this repo more closely
##########
datafusion/proto/tests/cases/roundtrip_physical_plan.rs:
##########
@@ -1736,3 +1737,55 @@ async fn roundtrip_physical_plan_node() {
let _ = plan.execute(0, ctx.task_ctx()).unwrap();
}
+
+#[tokio::test]
+async fn test_tpch_part_in_list_query_with_real_parquet_data() -> Result<()> {
Review Comment:
```suggestion
// Failing due to https://github.com/apache/datafusion/pull/16662
#[ignore]
#[tokio::test]
async fn test_tpch_part_in_list_query_with_real_parquet_data() -> Result<()>
{
```
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
