Skip to content

Python: a composite reports the data tables its children produce - #8684

Merged
jkschneider merged 1 commit into
mainfrom
fix/python-composite-data-table-aggregation
Aug 27, 2026
Merged

Python: a composite reports the data tables its children produce#8684
jkschneider merged 1 commit into
mainfrom
fix/python-composite-data-table-aggregation

Conversation

@mtthwcmpbll

@mtthwcmpbll mtthwcmpbll commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

RecipeDescriptor.from_recipe returned only the tables a recipe owns, so a Python composite whose tables all come from its recipe_list advertised none — the rows are still collected at run time, but nothing downstream can describe the table they belong to. Java's Recipe#createRecipeDescriptor already aggregates child tables via aggregateDataTableDescriptors, so Java composites are unaffected and this is a Python/Java parity gap; it needs a Python-authored composite whose table is owned by a child, which is why no shipped recipe hits it.

This unions a recipe's own tables with its children's, deduped by name and parent-first — sub-descriptors are built the same way, so the union is recursive. RpcRecipe gains an optional data_tables argument: it references a recipe on another peer by name and descriptors are built during marketplace registration when no peer is necessarily connected, so the delegate's tables can't be introspected and the composite author declares them. That also stops data_tables from falling into **options and being shipped to the delegate as a recipe option.

Verified with tests/test_composite_data_tables.py (5 of its 7 cases fail before the change, all pass after) and by running the customer-shaped recipes through _collect_marketplace_rows, where the composite's payload goes from [] to both tables with full column metadata. Full suite: 1882 passed; the 4 failures are pre-existing PEP 695 (type X = int) parse failures that also fail on a clean tree under Python 3.11. tests/rpc was not run — it needs the generated Java classpath.

This specifically addresses the bug reported in https://github.com/moderneinc/customer-requests/issues/3051

RecipeDescriptor.from_recipe returned only the tables a recipe owns, so a
composite whose tables all come from its recipe_list advertised none. Java's
Recipe#createRecipeDescriptor aggregates child tables
(aggregateDataTableDescriptors), so Java composites are unaffected and only
Python-authored ones lose them -- including from the marketplace listing,
which is what consumers resolve a run's data tables against. The rows are
still collected, but nothing downstream can describe the table they belong
to.

Union a recipe's own tables with its children's, deduped by name and
parent-first. Sub-descriptors are built the same way, so the union is
recursive.

RpcRecipe gains an optional data_tables argument. It references a recipe on
another peer by name, and descriptors are built during marketplace
registration when no peer is necessarily connected, so the delegate's tables
cannot be introspected here -- the composite author declares them. This also
stops data_tables from falling into **options and being shipped to the
delegate as a recipe option.
@github-project-automation github-project-automation Bot moved this from In Progress to Ready to Review in OpenRewrite Aug 27, 2026
@jkschneider
jkschneider merged commit ef72217 into main Aug 27, 2026
1 check passed
@jkschneider
jkschneider deleted the fix/python-composite-data-table-aggregation branch August 27, 2026 18:45
@github-project-automation github-project-automation Bot moved this from Ready to Review to Done in OpenRewrite Aug 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants