https://prefect-community.slack.com/archives/C04DZJC94DC/p1763146961194199?thread_ts=1763145223.026799&cid=C04DZJC94DC Is this right that a subflow inherits the

result_storage

from the parent flow, even if the subflow had its own

result_storage

set?

no

Related, I see

get_run_context()

first polls the

TaskRunContext

before the

FlowRunContext

(code). Does this mean that if I'm running a Flow under a Task with

result_storage

set, it will use that

result_storage

instead of its own?

do you have some example code that's behaving unexpectedly?

Yes 😬 but it's quite convoluted, with a Flow A -> Task -> Flow B, where Flow B is using Flow A's

result_storage

instead of its own. I'll set up a minimal reproducible example if it's helpful.

that'd be great, thanks!

from prefect import flow, task

@flow(log_prints=False)
def flow1():
    print('This should not be logged!') # <- This is logged!

@flow(log_prints=True)
def flow2():
    print('This should be logged!')
    task(flow1)()

if __name__ == "__main__":
    flow2()

This reproduces the problem

oh dang, can reproduce. will take a look

I see PR already out, thank you! https://github.com/PrefectHQ/prefect/pull/19450 I imagine it's not a common pattern to have this FlowA -> Task -> FlowB structure we have been running, so we just happened to expose it

its not super uncommon (it should be more common bc its often convenient!) but yea some of the engine machinery had some baked in assumptions from the old world (where tasks were rock bottom, and you couldnt call flows/tasks from them) if your situation allows direct-references, you can install from main once this is merged i.e install

git+<https://github.com/prefecthq/prefect.git@main>

with uv etc or even point at this branch until its merged into main (would not recommend bc we could merge/delete branch at any time)

Out of interest, what's the usual cadence from PR merge => new release?

we release on thursdays

Ok cool thanks for the context!