@Marvin is https://github.com/PrefectHQ/prefect/issues/15008 the "future" of how async/sync logic will be handled going forward?

✅ thought for 166.6 seconds

yes. tldr, explicit sync and async interfaces will be preferred over "dual/contextual" magic behavior based on what context the caller is in

so

await Thing.afunction()

or

Thing.function()

? How does that play with things like

.submit

and

.wait

?

Short answer: yes—that issue outlines the direction Prefect 3.x is moving toward, and it’s already underway. What that means in practice: - Move away from the implicit “magic” that decides sync vs async at runtime. - Provide explicit, dual implementations: - Methods gain async counterparts with an a-prefix (e.g.,

Block.load

and

Block.aload

). - Top-level functions follow the same pattern (e.g.,

run_deployment

now, planned

arun_deployment

). - For classes whose core behavior differs, async versions will be prefixed with

Async

(incremental rollout). - Over time, relying on implicit dispatch will be discouraged with warnings, then deprecated. What’s shipped so far in 3.x: - Explicit async methods are appearing, e.g.

Block.aload

alongside

Block.load

(confirmed). - Client-side split foundations exist (you’ll see separate async/sync client classes in the codebase), though naming is still settling as the migration proceeds. - Some rough edges are expected while this is rolled out, as seen in recent issues: - Jupyter returning a coroutine for

Block.load

in some contexts: https://github.com/PrefectHQ/prefect/issues/17877 - Async

run_deployment

patterns and result persistence quirks: https://github.com/PrefectHQ/prefect/issues/17557 The proposal itself, with the checklist of targets they’re migrating, is here: https://github.com/PrefectHQ/prefect/issues/15008 If you want to be future-proof today: - In async contexts, prefer explicit async APIs where they exist (e.g.,

await Block.aload(...)

). - In sync code, use the sync variants (

Block.load(...)

). - For deployments,

run_deployment

is currently the public sync entry point; an explicit

arun_deployment

is part of the plan but not broadly exposed yet. If you must parallelize from async code right now, call the sync function in a thread executor until the async variant lands cleanly. If you share your Prefect version and which APIs you’re using, I can suggest concrete patterns for your code. Or we can continue to tempt fate and rely on implicit magic—your call.

correct yea (also pretty good answer from marvin here) so when we introduce an async interface for futures, itll have an async

asubmit

method and an async

await

method. we only have a sync interface to futures now

Thanks!