Restore recipe hierarchy rows in SourcesFileResults

[timtebeek]

Summary

• Restore recursive hierarchy recording in RecipeRunCycle that was removed in Align estimated time savings between Result and SourcesFileResults #6022
• Hierarchy rows now use 0 for estimatedTimeSaving so the column remains summable
• Add test for multi-level recipe hierarchy

Problem

• The Sankey visualization shows recipe execution hierarchies by reading (parentRecipe, recipe) pairs from the SourcesFileResults data table. PR Align estimated time savings between Result and SourcesFileResults #6022 removed the recursive recording of hierarchy rows to fix non-summable estimatedTimeSaving values. This caused the Sankey to only show 1-2 levels instead of the full drill-down (5+ levels for migrations like Java 25).

Solution

Restore the recordSourceFileResult() method but pass 0L for estimatedTimeSaving on all non-leaf hierarchy rows. Only the leaf recipe that actually made the change carries its effort value. This gives the Sankey all the edges it needs while keeping the effort column summable.

Test plan

• Existing SourceFileResultsTest.hierarchical passes unchanged
• Existing RecipeEstimatedEffortTest.estimatedTimeSavingsForMultipleRecipes passes unchanged (effort sums still correct)
• New SourceFileResultsTest.deepHierarchyRecordsAllLevels verifies hierarchy rows are produced with zero effort

[timtebeek]

Any immediate thoughts here @pstreef given your involvement with

• Align estimated time savings between Result and SourcesFileResults #6022 ?

[pstreef]

yeah, perhaps we should just have a different data-table if this is just for 1 visualization? The reason for removal was more than just being able to sum. It was also confusing.

I would involve @jkschneider and/or @sambsnyd here for opinions

[sambsnyd]

I think this is reasonable. Peter's comments about it being a bit confusing are perfectly fair, but recording the hierarchy is a more accurate description of what happens when a recipe makes changes. Maybe mentioning the nature of the 0-savings rows in the data table description would help - although we don't surface those descriptions many places.

[timtebeek]

Thanks both! I'll merge as we're one to one restoring what was removed in #6022, with the exception of the effort which is explicitly set to zero and documented as such. I want to acknowledge that Peter suggested an alternative data table, but seeing how it would have to hook into RecipeRunCycle, and be attached for every run I think it'd be better not to introduce a near duplicate if the zero-time rows here work as well.