Workflow Run Types

Rebase Workflows are pipeline-style compositions of steps. They use Prefect's DAG and task execution model under the hood.

Workflows default to run_type="quick", which executes manual runs on a warm Cloud Run service worker backed by a Cloud Run-hosted Prefect API. Workflows accept quick or long; the quick_shared run type is functions-only.

For the full run-type overview across functions, models, and workflows, see Run Types.

Run Type Options

Set the run type on the workflow decorator:

import rebase as rb

project = rb.project("energy-forecasting")

@project.step()
def load_a(a: int = 0) -> dict:
    return {"value": a}

@project.step()
def load_b(b: int = 0) -> dict:
    return {"value": b}

@project.step()
def add_values(left: dict, right: dict) -> dict:
    return {"sum": left["value"] + right["value"]}

@project.workflow(name="add-workflow", run_type="long")
def add_workflow(a: int = 0, b: int = 0) -> dict:
    left = load_a(a)
    right = load_b(b)
    return add_values(left, right)

project.deploy()
print(add_workflow.remote(a=40, b=2))

@project.step(...) registers step bodies as internal workflow graph nodes. Step decorators do not take a run_type argument: steps execute in-flow, inside the workflow run's own infrastructure, so the workflow's run type covers every step.

The old backend= argument is removed and raises an error with a migration hint: backend="interactive" becomes run_type="quick", backend="batch" becomes run_type="long". The GKE-Prefect and Prefect Cloud paths no longer exist; see Run Types.

What Each Run Type Maps To

Both workflow run types are orchestrated by Rebase's self-hosted Prefect API, which itself runs on Cloud Run. Run records report the resolved infrastructure in the internal execution_backend field.

Scheduled runs always use the Cloud Run Jobs path so cron executions remain durable and provider-managed, regardless of the workflow's run type for manual runs.

Workflow runs of both run types are cancellable: rebase run cancel sets the Prefect flow run to cancelling and the worker stops the flow. rebase run logs reads Prefect's log API for both run types.

Platform Configuration

The mapping is configured by the platform, not by user code. The API service needs:

The helper script creates the Cloud Run Prefect API service, Cloud Run Jobs worker service, work pool, and runner deployment:

PROJECT_ID=rebase-agents \
REGION=europe-north1 \
IMAGE=europe-north1-docker.pkg.dev/rebase-agents/rebase-workflows/workflow-mvp:TAG \
PREFECT_DATABASE_URL=postgresql+asyncpg://... \
WORKFLOWS_DATABASE_URL=postgresql+asyncpg://... \
scripts/deploy_prefect_cloud_run_jobs.sh

Benchmark

Use the workflow benchmark when comparing the two workflow execution paths:

uv run python scripts/benchmark_workflow_backends.py \
  --backends prefect_cloud_run_jobs,prefect_cloud_run_service \
  --cases no_deps,boltons \
  --repetitions 2 \
  --output-json benchmark-results/workflows.json \
  --output-chart benchmark-results/workflows.png

The output separates registration time, backend provision time, provider submit time, result polling, SDK/API overhead, first run latency, and warm p50/p90/p95. For workflows, backend provision is normally zero per workflow because the Prefect infrastructure is deployed ahead of time; the queue, worker, and Cloud Run job startup costs appear in the run latency categories.