@ancient-wolf-19325 what will happen when I run

fl.current_context()

in a script which is not wrapped by flyte?

It seems likely that calling

fl.current_context()

(i.e.,

flytekit.current_context()

) in a script not wrapped by Flyte's core execution context will return a default or local context, not one populated with runtime execution parameters. This means you won't have access to workflow/task-specific metadata, secrets, or execution state—only the minimal defaults set for local or compilation contexts, as the context is managed by Flyte's core only during actual workflow/task execution or registration flows. This is supported by the implementation in the Flytekit source, where

current_context()

returns the current global context, which is only fully populated when running inside Flyte's managed environment or during local workflow execution with Flytekit's decorators and context managers (flytekit/core/context_manager.py). Would you like more detail on what fields are available in the default context or how to simulate a Flyte context locally? Sources: - flytekit/core/context_manager.py 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 So what will the execution id refer to?

If you call

flytekit.current_context().execution_id

in a script not wrapped by Flyte's core (i.e., outside a Flyte workflow/task execution), the

execution_id

will refer to a default or placeholder value, such as

ex:local:local:local

(a string) during compile time or local runs. It will not correspond to any real Flyte execution in the system, and the fields (project, domain, name) will be set to "local" or empty, as confirmed in github issue #2449. Would you like more detail on how this value changes in different execution contexts? Sources: - github issue #2449 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.