#3403 Re-translate LaunchPlan fixed inputs with remote context on registration Pull request opened by dansola Why are the changes needed? When a

LaunchPlan

is created with a

StructuredDataset

or

FlyteFile

as a

fixed_input

, flytekit eagerly serializes those inputs to Flyte literals at

LaunchPlan.create()

time using the local

FlyteContext

. At that point, the

FileAccessProvider

points to a local

/tmp

directory, so any file or dataset upload goes there instead of remote storage. When the launch plan is later registered, the serialized literal contains a

/tmp

path that the remote Flyte cluster cannot access. What changes were proposed in this pull request? •

LaunchPlan.__init__

now stores

_raw_fixed_inputs

, the original Python native values passed as

fixed_inputs

before they are serialized to a

LiteralMap

. •

LaunchPlan.create()

populates

_raw_fixed_inputs

alongside the existing

_saved_inputs

. •

FlyteRemote.register_launch_plan()

now re-translates

raw_fixed_inputs

using

self.context

, which has a

FileAccessProvider

configured for remote storage. This overwrites the stale local literals before the launch plan is serialized and sent to Flyte Admin. How was this patch tested? Added

test_register_launch_plan_retranslates_fixed_inputs_with_remote_context

in

tests/flytekit/unit/remote/test_remote.py

. The test creates a

LaunchPlan

with a

FlyteFile

fixed input and asserts that

translate_inputs_to_literals

is called with the remote context (

rr.context

) during

register_launch_plan

. The test was also verified to fail against the pre-fix code, confirming it catches the regression. flyteorg/flytekit