<@ULVA73B9P> All my flows on the worker pool are c...
# ask-marvin
c
@Marvin All my flows on the worker pool are crashing without logs. Only thing I can see is the crash event. Suddenly started happening yesterday without any changes from my side.
Copy code
"resource": {
    "prefect.resource.id": "prefect.flow-run.069fc8e6-1d41-78ea-8000-9ab38a61f8ad",
    "prefect.resource.name": "nebulous-seahorse",
    "prefect.run-count": "0",
    "prefect.state-message": "Process exited with status code: 1. Process exited with a general error.",
    "prefect.state-name": "Crashed",
    "prefect.state-timestamp": "2026-05-07T13:07:34.470503+00:00",
    "prefect.state-type": "CRASHED",
    "prefect.audit": "false"
  },
m
thought for 157.3 seconds
A generic
status code: 1
with no flow logs usually means the flow process is dying very early — often before Prefect finishes initializing run logging. So the most important place to look first is the worker logs, not the flow-run logs. What this usually means - The worker successfully picked up the run - It launched the flow subprocess - That subprocess exited almost immediately with a general error - Because it died early, nothing got emitted to the flow-run log stream Most common causes 1. Import / startup failure in the flow environment - missing package - broken dependency - syntax/import error in code imported at module load time - environment drift on the worker host/container 2. API connectivity/auth issue from the execution environment -
PREFECT_API_URL
unreachable - expired/changed
PREFECT_API_KEY
- DNS / proxy / firewall issue 3. Infrastructure/environment issue on the worker machine - disk full - memory pressure - broken Python environment / venv - changed filesystem path / working directory not available 4. A bad deployment/runtime config - invalid entrypoint - pull step failure - code path no longer available from the worker Since you said this started yesterday with no changes from your side, my strongest suspicions would be: - worker host/container environment drift - API/auth/connectivity problem - filesystem/network-mounted code path became unavailable - package/env issue due to a rebuilt image / restarted host / changed mount What to check right now 1. Open the worker logs for one crashed run In Prefect Cloud, the run event usually links to the worker. Look for anything just before the run is submitted/opened. 2. Turn on subprocess output streaming if not already enabled If you're using a process work pool, set:
Copy code
yaml
   job_variables:
     stream_output: true
That can surface stderr/stdout from the subprocess instead of leaving you with only the crash event. 3. Run the worker with more internal logging Start/restart the worker with:
Copy code
bash
   export PREFECT_LOGGING_INTERNAL_LEVEL=DEBUG
   prefect worker start --pool <your-pool-name>
4. Try executing one failed run manually from the same worker environment On the worker machine/container, with the same env:
Copy code
bash
   python -m prefect.engine 069fc8e6-1d41-78ea-8000-9ab38a61f8ad
If this is an import/startup problem, this often reveals the real traceback immediately. 5. Verify API connectivity from the worker environment
Copy code
bash
   echo $PREFECT_API_URL
   curl -I $PREFECT_API_URL/health
And confirm the API key is present in the worker environment. 6. Check the worker runtime itself
Copy code
bash
   python --version
   which python
   pip list
   df -h
   free -h
If this is containerized, also confirm the current image digest/tag is what you expect. 7. If your deployment uses pull steps or a working directory, verify that path still exists and is readable from the worker host/container. One important clue If all flows across the same worker pool started failing at once, that strongly points to a shared worker environment problem, not a bug in one flow. So I’d focus on: - worker restart/redeployment yesterday - image/package changes - expired credentials - broken network mount / repo checkout path - API connectivity from that worker environment Relevant references - Workers concept: docs.prefect.io/v3/concepts/workers - Work pools concept: docs.prefect.io/v3/concepts/work-pools - Running flows in local processes: run flows in local processes There are also related bug reports around generic exit-code-1 crashes where the underlying issue was only visible in worker-side logs:
- Process workers dying processing crashed hooks on Windows - Worker crashes after deleting a flow run - Scheduled runs crash with exit code 1 due to bad parameters If you want, send me: - your worker type (
process
, Docker, Kubernetes, etc.) - whether worker logs show anything right before/after
Opening process
- whether these deployments use pull steps / mounted code /
.from_source(...)
and I can help narrow this down fast.
c
@Marvin Its a prefect:managed worker.
m
thought for 19.1 seconds
Got it — that changes the likely causes a lot. If these are running on Prefect Managed Execution workers, then the worker host itself is not your machine, so the usual checks around your local venv, mounted paths, or host disk are much less likely. Given: - all flows on that pool are affected - no logs - it started suddenly - you’re using Prefect-managed workers this looks more like one of these: 1. A managed execution environment issue - platform-side runtime problem - region/runtime regression - image startup problem 2. A deployment/code-fetch problem common to all runs - your flows all rely on the same source repo / storage / pull step - auth to that source started failing - entrypoint/source resolution is failing very early 3. A workspace/auth/config problem affecting managed execution - execution environment can’t fetch code - required env vars/secrets are missing or invalid - API/auth interaction for those managed runs is failing before logs are initialized Because you don’t control the underlying worker host, the best signal now is the deployment definition and whether the code can be fetched and imported by managed infrastructure. Most useful things to check next 1. Did all affected deployments share the same code source? For example: - same GitHub repo - same branch/tag - same storage location - same
.from_source(...)
- same pull steps If yes, a code fetch/auth issue is very likely. 2. Did a secret/token used for source access expire yesterday? Common examples: - GitHub token rotated/expired - cloud storage credentials changed - private package index credentials changed 3. Did the repo contents change even if “you changed nothing” operationally? For example: - default branch updated - dependency version drift - package removed from lockfile/image install step - import-time error introduced in shared module 4. Try one very simple test deployment in the same managed pool A trivial flow with no external imports and no private source dependency:
Copy code
python
   from prefect import flow

   @flow
   def smoke_test():
       print("hello")

   if __name__ == "__main__":
       smoke_test.serve(name="smoke-test")
If that also crashes in the same managed pool, it strongly suggests a managed-execution/platform issue rather than your code. 5. Compare one failing deployment’s source setup I’d specifically look for: - private repo access - pull steps - custom package install at runtime - env vars/secrets required before import Important note on logs With managed workers, if the process dies before Prefect engine logging is initialized or before code-fetch/import fully succeeds, you can end up with exactly what you’re seeing: just a crash event and no normal run logs. What I’d do immediately - launch a minimal smoke-test deployment into the same managed pool - check whether all broken deployments share the same source/auth pattern - check whether any secret/token used for source retrieval changed/expired yesterday If the smoke test also fails, this is very likely not your flow code. Since I can’t escalate on your behalf, the right path for a likely managed-platform issue is: - contact Prefect here: prefect.io/contact If you want, send me: - how these deployments are sourced (
from_source
, Git repo, S3, etc.) - whether the code source is private - whether a trivial smoke-test flow in the same managed pool also crashes and I can help you determine if this is source/auth related vs managed infrastructure related.
c
How do i do What I’d do immediately - launch a minimal smoke-test deployment into the same managed pool
@Marvin How do I do What I’d do immediately - launch a minimal smoke-test deployment into the same managed pool
m
thought for 96.3 seconds
Yep — for a Prefect-managed pool, the easiest smoke test is: 1. make a tiny flow 2. deploy it to the same work pool 3. run it 4. see whether that also crashes Because this is Prefect 3.x, use
deploy
, not
serve
. Important caveat for managed pools: your code needs to be available to Prefect-managed infrastructure, typically via
.from_source(...)
from a Git repo or other remote source. A managed pool cannot use code sitting only on your laptop. Minimal smoke test example Create a file like `smoke_test.py`:
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/<your-org>/<your-repo>.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="<your-managed-pool-name>",
    )
Then run:
Copy code
bash
python smoke_test.py
That creates a deployment named
smoke-test
in the same pool. Then trigger it from the UI or CLI. If you want to run it from CLI:
Copy code
bash
prefect deployment run "smoke-test/smoke-test"
How to find the deployment name The full deployment name is generally:
Copy code
text
<flow-name>/<deployment-name>
So in the example above: - flow name =
smoke_test
- deployment name =
smoke-test
which usually becomes:
Copy code
text
smoke_test/smoke-test
If you want to confirm, check in the Deployments page in Prefect Cloud. If your repo is private You’ll need the managed environment to be able to access it. If your normal deployments already use the same private source successfully, reuse that same source/auth pattern for the smoke test. Even simpler diagnostic variant If your existing deployments already come from the same repo, add this tiny file to that repo and deploy from the same source mechanism. That helps isolate whether: - the pool/platform is broken, or - your existing flow code/imports are broken What the result means - If the smoke test succeeds: the managed pool itself is probably okay, and the issue is likely in your shared code source, imports, secrets, or deployment config. - If the smoke test also crashes with no logs: that strongly suggests a managed execution/platform issue or a common source-fetch/auth problem. UI option You can also create a deployment from code you already have in a repo and then run it from the Prefect Cloud UI: - open Deployments - select the new deployment - click Run Docs - Work pools - Workers If you want, I can give you a copy-paste exact version of this for: - a public GitHub repo - a private GitHub repo - or based on how your current deployments are created now
c
@Marvin christianhenrikjohansenvestre@Christian-sin-MacBook-Air integrations % uv run python smoke_test.py 154422.330 | DEBUG | prefect.profiles - Using profile 'default' 154422.338 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Running call coroutine_wrapper() in thread 'RunSyncEventLoopThread' 154422.338 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154422.338 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' COMPLETED, runtime=0.00> exited 154422.338 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Scheduling coroutine for call coroutine_wrapper(<dropped>) in running loop <_UnixSelectorEventLoop running=True closed=False debug=False> 154422.338 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154422.340 | DEBUG | prefect.runner.storage.git-repository.integrations - Pulling contents from repository 'integrations' to '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmp8o2kau9e/integrations'... 154422.340 | DEBUG | prefect.runner.storage.git-repository.integrations - Cloning repository https://github.com/Amundsen-Sports/integrations.git 154424.647 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' COMPLETED, runtime=2.31> exited 154424.647 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Finished async call coroutine_wrapper(<dropped>) Traceback (most recent call last): File "<frozen importlib._bootstrap_external>", line 936, in exec_module File "<frozen importlib._bootstrap_external>", line 1073, in get_code File "<frozen importlib._bootstrap_external>", line 1130, in get_data FileNotFoundError: [Errno 2] No such file or directory: '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmp8o2kau9e/integrations/smoke_test.py' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 2573, in load_flow_from_entrypoint flow: Flow[P, Any] = import_object(entrypoint) # pyright: ignore[reportRedeclaration] ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/importtools.py", line 153, in import_object module = load_script_as_module(script_path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/importtools.py", line 118, in load_script_as_module raise ScriptError(user_exc=exc, path=path) from exc prefect.exceptions.ScriptError: Script at '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmp8o2kau9e/integrations/smoke_test.py' encountered an exception: FileNotFoundError(2, 'No such file or directory') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/smoke_test.py", line 8, in <module> flow.from_source( File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/compatibility/async_dispatch.py", line 94, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1379, in from_source flow = load_flow_from_entrypoint(full_entrypoint) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 2582, in load_flow_from_entrypoint flow: Optional[Flow[P, Any]] = safe_load_flow_from_entrypoint(entrypoint) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 2963, in safe_load_flow_from_entrypoint func_or_cls_def, source_code, parts = _entrypoint_definition_and_source(entrypoint) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 3236, in _entrypoint_definition_and_source source_code = Path(path).read_text() ^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/pathlib.py", line 1058, in read_text with self.open(mode='r', encoding=encoding, errors=errors) as f: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/pathlib.py", line 1044, in open return io.open(self, mode, buffering, encoding, errors, newline) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FileNotFoundError: [Errno 2] No such file or directory: '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmp8o2kau9e/integrations/smoke_test.py'
m
thought for 12.5 seconds
That error is actually good news: your test failed locally during deployment creation, not in the managed pool. What happened
from_source(...)
clones the repo and then tries to load:
Copy code
text
smoke_test.py:smoke_test
But after cloning
<https://github.com/Amundsen-Sports/integrations.git>
, Prefect could not find
smoke_test.py
in that repo snapshot:
Copy code
text
FileNotFoundError: .../integrations/smoke_test.py
So the issue is just that the
entrypoint
path does not exist in the cloned repo. Why this happened Most likely one of these: -
smoke_test.py
is only on your laptop and has not been committed/pushed - the file is in a subdirectory, not repo root - the branch you cloned doesn’t contain the file - the repo default branch is not the branch where the file lives How to fix it Option 1: commit and push
smoke_test.py
to the repo root
If the file should be at the top level of the repo, make sure it is pushed, then keep:
Copy code
python
entrypoint="smoke_test.py:smoke_test"
Option 2: use the correct relative path If the file is in a folder, use that path instead, for example:
Copy code
python
entrypoint="flows/smoke_test.py:smoke_test"
or
Copy code
python
entrypoint="src/smoke_test.py:smoke_test"
Option 3: pin the branch explicitly If the file is on a non-default branch:
Copy code
python
flow.from_source(
    source="<https://github.com/Amundsen-Sports/integrations.git@your-branch>",
    entrypoint="smoke_test.py:smoke_test",
).deploy(
    name="smoke-test",
    work_pool_name="<your-managed-pool-name>",
)
Recommended exact next step First verify the file exists in the remote repo path you reference. For example, if the file is in repo root, then after pushing it, use:
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/Amundsen-Sports/integrations.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="<your-managed-pool-name>",
    )
If it’s in a subfolder, change only the
entrypoint
. How to sanity check before rerunning Make sure the file is actually in GitHub at the path you use. The important rule is:
Copy code
text
entrypoint = <path inside repo>:<flow function name>
So if GitHub shows: - repo root:
smoke_test.py
smoke_test.py:smoke_test
-
prefect/smoke_test.py
prefect/smoke_test.py:smoke_test
What this means diagnostically This does not yet tell us whether the managed pool is healthy. It only tells us the deployment script hasn’t successfully created the test deployment yet. Once you fix the repo path and deploy successfully, then run the smoke test in the managed pool: - if it succeeds, the managed pool likely works - if it crashes the same way, that’s a strong signal of a managed execution or shared source issue If you want, paste: - the repo-relative location of
smoke_test.py
- the pool name and I’ll give you the exact corrected
from_source(...).deploy(...)
snippet.
c
@Marvin christianhenrikjohansenvestre@Christian-sin-MacBook-Air integrations % uv run python smoke_test.py 154943.830 | DEBUG | prefect.profiles - Using profile 'default' 154943.838 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Running call coroutine_wrapper() in thread 'RunSyncEventLoopThread' 154943.838 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154943.838 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' COMPLETED, runtime=0.00> exited 154943.838 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Scheduling coroutine for call coroutine_wrapper(<dropped>) in running loop <_UnixSelectorEventLoop running=True closed=False debug=False> 154943.838 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154943.840 | DEBUG | prefect.runner.storage.git-repository.integrations - Pulling contents from repository 'integrations' to '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmpzrsjr_7_/integrations'... 154943.840 | DEBUG | prefect.runner.storage.git-repository.integrations - Cloning repository https://github.com/Amundsen-Sports/integrations.git 154947.656 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' COMPLETED, runtime=3.82> exited 154947.656 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Finished async call coroutine_wrapper(<dropped>) 154947.679 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Running call coroutine_wrapper() in thread 'RunSyncEventLoopThread' 154947.679 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154947.679 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <WatcherThreadCancelScope, name='coroutine_wrapper' COMPLETED, runtime=0.00> exited 154947.679 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Scheduling coroutine for call coroutine_wrapper(<dropped>) in running loop <_UnixSelectorEventLoop running=True closed=False debug=False> 154947.679 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' RUNNING, runtime=0.00> entered 154947.686 | DEBUG | prefect.client - Connecting to API at https://api.prefect.cloud 154947.893 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - <AsyncCancelScope, name='coroutine_wrapper' COMPLETED, runtime=0.21> exited 154947.893 | DEBUG | RunSyncEventLoopThread | prefect._internal.concurrency - Encountered exception in async call coroutine_wrapper(<dropped>) Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 419, in read_work_pool response = await self.request( ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/base.py", line 53, in request return await self._client.send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 379, in send response.raise_for_status() File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 163, in raise_for_status raise PrefectHTTPStatusError.from_httpx_error(exc) from exc.cause prefect.exceptions.PrefectHTTPStatusError: Client error '404 Not Found' for url 'https://api.prefect.cloud/work_pools/worker' For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404 The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1518, in deploy work_pool = await client.read_work_pool(work_pool_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 427, in read_work_pool raise ObjectNotFound(http_exc=e) from e prefect.exceptions.ObjectNotFound: None The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 441, in _run_async result = await coro ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 188, in coroutine_wrapper return await task ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 341, in ctx_call result = await async_fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1526, in deploy raise ValueError( ValueError: Could not find work pool 'worker'. Please create it before deploying this flow. Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 419, in read_work_pool response = await self.request( ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/base.py", line 53, in request return await self._client.send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 379, in send response.raise_for_status() File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 163, in raise_for_status raise PrefectHTTPStatusError.from_httpx_error(exc) from exc.cause prefect.exceptions.PrefectHTTPStatusError: Client error '404 Not Found' for url 'https://api.prefect.cloud/work_pools/worker' For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404 The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1518, in deploy work_pool = await client.read_work_pool(work_pool_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 427, in read_work_pool raise ObjectNotFound(http_exc=e) from e prefect.exceptions.ObjectNotFound: None The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/smoke_test.py", line 11, in <module> ).deploy( ^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 351, in coroutine_wrapper return run_coro_as_sync(ctx_call()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 207, in run_coro_as_sync return call.result() ^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 365, in result return self.future.result(timeout=timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 192, in result return self.__get_result() ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/concurrent/futures/_base.py", line 401, in __get_result raise self._exception File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 441, in _run_async result = await coro ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 188, in coroutine_wrapper return await task ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 341, in ctx_call result = await async_fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1526, in deploy raise ValueError( ValueError: Could not find work pool 'worker'. Please create it before deploying this flow.
m
Your message was too long, here's your message at the allowed limit: christianhenrikjohansenvestre@Christian-sin-MacBook-Air integrations % uv run python smoke_test py 15 49 43 830 | DEBUG | prefect profiles - Using profile 'default' 15 49 43 838 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Running call coroutine_wrapper() in thread 'RunSyncEventLoopThread' 15 49 43 838 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <WatcherThreadCancelScope name='coroutine_wrapper' RUNNING runtime=0 00> entered 15 49 43 838 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <WatcherThreadCancelScope name='coroutine_wrapper' COMPLETED runtime=0 00> exited 15 49 43 838 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Scheduling coroutine for call coroutine_wrapper(<dropped>) in running loop <_UnixSelectorEventLoop running=True closed=False debug=False> 15 49 43 838 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <AsyncCancelScope name='coroutine_wrapper' RUNNING runtime=0 00> entered 15 49 43 840 | DEBUG | prefect runner storage git-repository integrations - Pulling contents from repository 'integrations' to '/var/folders/8m/fht9q9wd2p9cv84vmztcm5sc0000gn/T/tmpzrsjr_7_/integrations' 15 49 43 840 | DEBUG | prefect runner storage git-repository integrations - Cloning repository <https //github com/Amundsen-Sports/integrations git> 15 49 47 656 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <AsyncCancelScope name='coroutine_wrapper' COMPLETED runtime=3 82> exited 15 49 47 656 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Finished async call coroutine_wrapper(<dropped>) 15 49 47 679 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Running call coroutine_wrapper() in thread 'RunSyncEventLoopThread' 15 49 47 679 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <WatcherThreadCancelScope name='coroutine_wrapper' RUNNING runtime=0 00> entered 15 49 47 679 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <WatcherThreadCancelScope name='coroutine_wrapper' COMPLETED runtime=0 00> exited 15 49 47 679 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Scheduling coroutine for call coroutine_wrapper(<dropped>) in running loop <_UnixSelectorEventLoop running=True closed=False debug=False> 15 49 47 679 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <AsyncCancelScope name='coroutine_wrapper' RUNNING runtime=0 00> entered 15 49 47 686 | DEBUG | prefect client - Connecting to API at <https //api prefect cloud> 15 49 47 893 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - <AsyncCancelScope name='coroutine_wrapper' COMPLETED runtime=0 21> exited 15 49 47 893 | DEBUG | RunSyncEventLoopThread | prefect _internal concurrency - Encountered exception in async call coroutine_wrapper(<dropped>) Traceback (most recent call last) File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/client/orchestration/_work_pools/client py line 419 in read_work_pool response = await self request( ^^^^^^^^^^^^^^^^^^^ File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/client/orchestration/base py line 53 in request return await self _client send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/client/base py line 379 in send response raise_for_status() File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/client/base py line 163 in raise_for_status raise PrefectHTTPStatusError from_httpx_error(exc) from exc cause prefect exceptions PrefectHTTPStatusError Client error '404 Not Found' for url '<https //api
prefect cloud/work_pools/worker>' For more information check <https //developer mozilla org/en-US/docs/Web/HTTP/Status/404> The above exception was the direct cause of the following exception Traceback (most recent call last) File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/flows py line 1518 in deploy work_pool = await client read_work_pool(work_pool_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File /Users/christianhenrikjohansenvestre/Utvikling/integrations/ venv/lib/python3 11/site-packages/prefect/client/orchestration/_work_pools/client py line 427 in read_work_pool raise ObjectNotFound(http_exc=e) from e prefect exceptions ObjectNotFound None The above exception was the direct cause of the following exception Traceback (most recent call
c
@Marvin prefect.exceptions.PrefectHTTPStatusError: Client error '404 Not Found' for url 'https://api.prefect.cloud/work_pools/worker' For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404 The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1518, in deploy work_pool = await client.read_work_pool(work_pool_name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 427, in read_work_pool raise ObjectNotFound(http_exc=e) from e prefect.exceptions.ObjectNotFound: None The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/smoke_test.py", line 11, in <module> ).deploy( ^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 351, in coroutine_wrapper return run_coro_as_sync(ctx_call()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 207, in run_coro_as_sync return call.result() ^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 365, in result return self.future.result(timeout=timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 192, in result return self.__get_result() ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/concurrent/futures/_base.py", line 401, in __get_result raise self._exception File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/_internal/concurrency/calls.py", line 441, in _run_async result = await coro ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 188, in coroutine_wrapper return await task ^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/utilities/asyncutils.py", line 341, in ctx_call result = await async_fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/flows.py", line 1526, in deploy raise ValueError( ValueError: Could not find work pool 'worker'. Please create it before deploying this flow.
m
thought for 14.3 seconds
Yep — this is a separate, simpler problem:
deploy()
is trying to use a work pool named:
Copy code
text
worker
and that work pool does not exist in your current workspace. So the smoke test hasn’t been deployed yet. What this means Your code is reaching Prefect Cloud successfully now, but the
work_pool_name
you passed is wrong. The key line is:
Copy code
text
ValueError: Could not find work pool 'worker'
So somewhere you have:
Copy code
python
work_pool_name="worker"
but
worker
is not the actual pool name. How to fix it Use the exact name of the Prefect-managed work pool that your failing deployments are using. If you don’t know it, find it in either place: 1. Prefect Cloud UI - go to Work Pools - copy the exact pool name 2. CLI Run:
Copy code
bash
   prefect work-pool ls
Then update your smoke test to use that exact name:
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/Amundsen-Sports/integrations.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="<actual-pool-name>",
    )
Example If the real pool is called
managed-prod
, then:
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/Amundsen-Sports/integrations.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="managed-prod",
    )
Then run:
Copy code
bash
uv run python smoke_test.py
After it deploys successfully, trigger it from the UI or:
Copy code
bash
prefect deployment run "smoke_test/smoke-test"
Why the URL looked weird This part:
Copy code
text
<https://api.prefect.cloud/work_pools/worker>
suggests your client is trying to read the work pool by name and got a 404 because that pool name doesn’t exist in the current workspace/account context. Two things to double-check 1. You’re in the right workspace/profile
Copy code
bash
   prefect profile ls
   prefect config view
Make sure your
PREFECT_API_URL
points to the workspace where that managed pool exists. 2. The pool name matches exactly, including spaces/case. Next best step Run:
Copy code
bash
prefect work-pool ls
and paste the output here if you want — I can tell you exactly which name to use.
c
@Marvin christianhenrikjohansenvestre@Christian-sin-MacBook-Air integrations % uv run prefect work-pool ls 155329.974 | DEBUG | prefect.profiles - Using profile 'default' 155330.154 | DEBUG | prefect.client - Connecting to API at https://api.prefect.cloud Traceback (most recent call last): File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/cli/_utilities.py", line 44, in wrapper return fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/cli/_types.py", line 159, in sync_fn return asyncio.run(async_fn(*args, **kwargs)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/asyncio/runners.py", line 190, in run return runner.run(main) ^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/asyncio/runners.py", line 118, in run return self._loop.run_until_complete(task) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/.local/share/uv/python/cpython-3.11.14-macos-aarch64-none/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/cli/work_pool.py", line 294, in ls pools = await client.read_work_pools() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/_work_pools/client.py", line 457, in read_work_pools response = await self.request("POST", "/work_pools/filter", json=body) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/orchestration/base.py", line 53, in request return await self._client.send(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 379, in send response.raise_for_status() File "/Users/christianhenrikjohansenvestre/Utvikling/integrations/.venv/lib/python3.11/site-packages/prefect/client/base.py", line 163, in raise_for_status raise PrefectHTTPStatusError.from_httpx_error(exc) from exc.cause prefect.exceptions.PrefectHTTPStatusError: Client error '404 Not Found' for url 'https://api.prefect.cloud/work_pools/filter' For more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404 An exception occurred. christianhenrikjohansenv
m
thought for 14.8 seconds
Aha — this is the real issue. Your CLI is pointed at the base Cloud domain:
Copy code
text
<https://api.prefect.cloud>
but Prefect expects
PREFECT_API_URL
to include your account/workspace API path, something like:
Copy code
text
<https://api.prefect.cloud/api/accounts/<account-id>/workspaces/<workspace-id>>
That’s why commands like
work-pool ls
are hitting:
Copy code
text
<https://api.prefect.cloud/work_pools/filter>
and getting 404. They should be hitting the workspace-scoped API path instead. So right now your local client is misconfigured. Fix it Run:
Copy code
bash
prefect cloud login
and select the correct workspace. That should set the proper workspace-scoped API URL for your active profile. Then verify with:
Copy code
bash
prefect config view
You want to see something like:
Copy code
text
PREFECT_API_URL='<https://api.prefect.cloud/api/accounts/<account-id>/workspaces/<workspace-id>>'
Not just:
Copy code
text
<https://api.prefect.cloud>
After that, retry:
Copy code
bash
prefect work-pool ls
or with uv if that’s how you’re running Prefect:
Copy code
bash
uv run prefect work-pool ls
If you want to set it directly You can also do:
Copy code
bash
prefect config set PREFECT_API_URL="<https://api.prefect.cloud/api/accounts/<account-id>/workspaces/<workspace-id>>"
and ensure your API key is set too:
Copy code
bash
prefect config set PREFECT_API_KEY="<your-api-key>"
But
prefect cloud login
is usually easiest. Why this matters for your original crash issue This misconfiguration is local to your CLI/deploy commands, so it may or may not be related to the managed-pool crashes themselves. But it does explain: - why
work-pool ls
fails - why deploy couldn’t find the work pool - why your smoke test deployment hasn’t been created yet Recommended next steps 1. Run:
Copy code
bash
   prefect cloud login
2. Confirm:
Copy code
bash
   prefect config view
3. List pools:
Copy code
bash
   prefect work-pool ls
4. Update
work_pool_name
in
smoke_test.py
to the exact managed pool name 5. Deploy again:
Copy code
bash
   uv run python smoke_test.py
6. Run the smoke test deployment If you paste the output of:
Copy code
bash
prefect config view
after login, I can confirm whether it’s fixed before you try again.
c
@Marvin it failed probably because it didnt have github auth in the deployment, should i change it?
m
thought for 12.8 seconds
Yes — if the repo is private, then that is a very plausible cause, and yes, you should change the smoke test to use the same source/auth pattern as your real deployments. A Prefect-managed pool has to fetch your code remotely. If the repo is private and the deployment doesn’t include working auth, the run can fail very early — often with little or no useful flow logs. That would also fit your original symptom pretty well. What to do Make the smoke test match the same code retrieval method as the failing deployments: - same repo - same branch - same auth method - same source configuration Because if you test with a different source setup, you’re not isolating the right thing. Important diagnostic logic - If your real deployments use a private GitHub repo and managed execution - and GitHub access broke yesterday - then all runs in that pool could suddenly start crashing early So yes, this is worth checking immediately. Best next test Instead of inventing a brand-new source setup, create the smoke test in the same repo and deploy it the same way your current flows are deployed. That answers: - can managed execution still fetch this repo? - can it import a trivial flow from this repo? - or is repo access itself broken? What I need to know to tell you the exact change Can you paste one of these from an existing working/failing deployment definition: - the Python deploy code you use now, or - the relevant
prefect.yaml
, or - whether you use: - public GitHub - private GitHub with token - Prefect Git block / credentials - another storage source One important note If this is Prefect 3.x, don’t switch to old 2.x-style GitHub storage block patterns. For 3.x, the recommended pattern is using
.from_source(...)
with a reachable source, plus the correct credentials/access arrangement where needed. Also, if your local CLI is still pointed at the wrong API URL, fix that first with:
Copy code
bash
prefect cloud login
Then inspect one existing deployment in the UI and compare its source configuration to the smoke test. My recommendation Yes: 1. fix local Cloud login/profile 2. make the smoke test use the same private repo auth/source mechanism as the failing deployments 3. rerun it If you paste your current deployment code, I’ll rewrite the smoke test so it matches exactly.
c
@Marvin i fixed the prefect login, so its only the private repo thing that files How should this look?
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/Amundsen-Sports/integrations.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="<actual-pool-name>",
    )
m
thought for 16.6 seconds
Yes — structurally that looks right, but for a private GitHub repo you need to make sure the managed runtime can authenticate to GitHub. Also, remove the angle brackets around the URL and use the real pool name. A corrected basic version is:
Copy code
python
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    flow.from_source(
        source="<https://github.com/Amundsen-Sports/integrations.git>",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="YOUR_ACTUAL_POOL_NAME",
    )
But the key question is: how do your existing deployments authenticate to that private repo? Because the smoke test should use the same mechanism. If your existing deployments already work by embedding auth in the source URL It might look like this pattern:
Copy code
python
flow.from_source(
    source="https://<token>@github.com/Amundsen-Sports/integrations.git",
    entrypoint="smoke_test.py:smoke_test",
).deploy(
    name="smoke-test",
    work_pool_name="YOUR_ACTUAL_POOL_NAME",
)
But I do not recommend hardcoding a token directly in code unless that is truly temporary for debugging. Better approach Use the same secret/env-var pattern your real deployment uses. For example, if you already inject a GitHub token as an environment variable during deployment creation, you may build the URL from that:
Copy code
python
import os
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    github_token = os.environ["GITHUB_TOKEN"]

    flow.from_source(
        source=f"https://{github_token}@github.com/Amundsen-Sports/integrations.git",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="YOUR_ACTUAL_POOL_NAME",
    )
Important caveat This only helps if Prefect uses that authenticated source definition when creating/running the deployment. The core issue is that the managed execution environment must be able to fetch the repo too. So the real test is: - does one of your existing deployments already have working private-repo access configured? - if yes, mirror that exactly What I would do here Take one currently failing deployment that already points at this repo and copy: - its
source
- its branch/ref - any auth pattern - its pool name Then change only: - flow entrypoint →
smoke_test.py:smoke_test
- deployment name →
smoke-test
That gives you a true apples-to-apples test. Two common gotchas 1. Wrong entrypoint path If
smoke_test.py
is not at repo root, use the repo-relative path:
Copy code
python
   entrypoint="path/to/smoke_test.py:smoke_test"
2. Wrong branch If the file exists only on a branch, specify it in the source URL:
Copy code
python
   source="<https://github.com/Amundsen-Sports/integrations.git@your-branch>"
So the minimal final form is probably something like:
Copy code
python
import os
from prefect import flow

@flow(log_prints=True)
def smoke_test():
    print("smoke test ran successfully")

if __name__ == "__main__":
    github_token = os.environ["GITHUB_TOKEN"]

    flow.from_source(
        source=f"https://{github_token}@github.com/Amundsen-Sports/integrations.git@main",
        entrypoint="smoke_test.py:smoke_test",
    ).deploy(
        name="smoke-test",
        work_pool_name="YOUR_ACTUAL_POOL_NAME",
    )
But only use that if this matches how your existing deployments access GitHub. If you want, paste one real deployment snippet you currently use for this repo, and I’ll convert it into the exact smoke-test version.