child_auth

How a background DAG child process obtains its credentials and configuration.

A background DAG run executes in a subprocess Prefect launches from a served deployment, so it inherits nothing from the pod. On the Docker path the credential costs nothing — BITFOUNT_API_KEY_ID / BITFOUNT_API_KEY are in the environment the Runner passes down, and _create_bitfount_session picks them up on its own.

The desktop path is the hard one. There the pod's own credential is a RefreshableJWT whose get_token is bound to a live multiprocessing.Queue back to the orchestrator, and neither a queue handle nor a bearer token can travel as a JSON deployment parameter — the first because it is not serialisable, the second because deployment parameters are persisted in the Prefect database in clear. The same is true of ehr_config, which carries a private key.

So the child asks the pod instead. It presents the nonce the pod left for it in the cache (cache.types.background_run_grants) to the pod control server's child-config endpoint, over loopback, and gets back a real token — or, for the "config" kind, the EHR configuration and the hook factories to re-register. A grant is redeemable repeatedly and for the life of the run, because a run that outlives its first token refreshes mid-flight.

---