[KAJdev]

Part of CON-1833.

Bootstrap registered tasks from the environment's artifact and execute them with JSON arguments. Readiness waits for initialization, execution caps cannot be extended, and self-cleanup uses the pod's runtime credential. Dev execution remains source-based.

Release the runtime package and task images before runpod-python#644. Task lifecycle authorization requires RunPod#6686.

[Copilot]

🟡 Changes recommended

Deployment-mode fallback and initialization lifecycle issues can bypass execution restrictions or prevent valid tasks from running successfully.

3 open issues

• Validate deployment identity to prevent unintended source mode · New
• Run initialization and task execution on the same event loop · New
• Start watchdog monitoring only after initialization completes · New

What changed in this PR

Adds registered Flash task execution to the shared runtime bootstrap, using deployed artifacts and JSON arguments while preserving source-based development execution.

Changes:

• Loads registered tasks and runs initialization before reporting readiness.
• Adds production request restrictions, execution timeout caps, and pod-authenticated cleanup.
• Documents deployed task behavior and adds lifecycle and transport tests.

File	Description
tests/​test_deployed_task.py	Tests deployment bootstrap, JSON execution, readiness, timeouts, and cleanup.
src/​runpod_sdk_runtime/​task/​runner.py	Adds production execution routing, readiness handling, timeout caps, and task cleanup authentication.
src/​runpod_sdk_runtime/​task/​deployed.py	Loads registered task handles, initializes them, and validates JSON requests.
src/​runpod_sdk_runtime/​executor.py	Supports prepared functions and strict JSON result serialization.
src/​runpod_sdk_runtime/​bootstrap.py	Adds task runtime selection, identity validation, and bootstrap error reporting.
README.md	Documents deployed task configuration, execution, and cleanup.

_{Review effort: Balanced}

[deanq]

When bootstrap or init fails, /ping now answers 500 with the BootstrapError payload, but wait_ready in runpod-python#644 (runpod/apps/tasks.py) only returns on 200 and treats every other status as "not ready yet" until READY_TIMEOUT (600s). So a deterministic failure (manifest mismatch, missing env var, an exception in the init hook) makes the caller wait 10 minutes on a billed pod and then get a generic "did not become ready" TimeoutError instead of the error the README promises.

Separately, /ping is the one route without token auth and the task port is exposed through the pod proxy, so anyone with the pod id can read task initialization failed: {exc}, which comes straight from user init code or pip/apt stderr. Could unauthenticated /ping return just {"ready": false} (plus error_type) and serve the message on an authed route? Then wait_ready can treat a 500 as terminal, fetch the details with the token, and raise them right away.

[deanq]

flashTaskCreate resolves environment.activeBuildId and approves the task's image, env, compute and timeout from that build's resourceSpec, and the host then delivers "the environment's active artifact" at boot. If a deploy flips activeBuildId between create and boot, the pod can run the new build's code under the old build's policy. The runner checks app and resource name but nothing compares the artifact to RUNPOD_BUILD_ID, so it only has to be non-empty. Is the host pinning delivery to the pod's build? If not, it might be worth having the manifest carry its build id (or the host pass the expected artifact hash) so _task_resource can reject a mismatch.