voonhous opened a new issue, #19639: URL: https://github.com/apache/hudi/issues/19639
**Describe the problem** `show_clean_plans(showArchived => true)` returns all-null rows for archived clean plans. `getCleanerPlans` (`ShowCleansPlanProcedure.scala:185-202`) collects archived clean instants from `metaClient.getArchivedTimeline`, but then hands every instant to `processCleanPlan(metaClient, metaClient.getActiveTimeline, cleanInstant)`. Reading the plan of an archived instant off the active timeline fails; the failure is swallowed and `createErrorRow` emits a row whose columns are all null. The sibling `ShowCleansProcedure` gets this right: it reads archived results through `metaClient.getArchivedTimeline` (`ShowCleansProcedure.scala:167-172`), which shows the asymmetry is an oversight, not a design choice. The pre-existing `showArchived` test never triggers archival (too few commits), so its `allPlans.length >= activePlans.length` assertion passes at equality and the bug goes unnoticed. **To reproduce** Configure aggressive archival (low `hoodie.keep.min.commits` / `hoodie.keep.max.commits`), produce several clean instants, let the timeline archive them, then `call show_clean_plans(table => 't', showArchived => true)`: the archived rows come back with null `policy`, `earliest_instant_to_retain`, etc. **Suggested fix** Pass the archived timeline when processing archived instants, mirroring `ShowCleansProcedure`. Regression coverage: an archival-forcing test in `TestShowCleansProcedures` asserting non-null plan fields for an archived row. -- 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]
