Back to Claude Scientific Skills

Operations, Registration, Debugging, and Execution

skills/latchbio-integration/references/operations-and-debugging.md

2.55.08.3 KB
Original Source

Operations, Registration, Debugging, and Execution

This reference targets the current stable CLI and SDK (latch==2.76.8).

Authenticate and Select a Workspace

bash
latch login
latch workspace

Select a known workspace by numeric ID:

bash
latch workspace --id 12345

The active workspace controls unqualified latch:/// paths, Registry access, workflow registration, and programmatic execution. Surface it before a destructive or costly action.

Do not read or print ~/.latch/token. Use the CLI's supported login and token handling.

Registration

Basic remote registration:

bash
latch register --yes --open .

Remote builds are the default:

bash
latch register --remote .

Use a local Docker build only when intentional:

bash
latch register --no-remote .

Important options:

bash
# Register into another workspace
latch register --workspace-id 12345 .

# Mark the version as a release
latch register --mark-as-release .

# Register workflows from a non-default Python module
latch register --workflow-module wf.custom_entrypoint .

# Use a specific Dockerfile
latch register --dockerfile Dockerfile.release .

# Plain build output for CI logs
latch register --docker-progress plain .

Version behavior

Registration combines the project version with automatic content/version information unless disabled. Do not disable automatic versioning merely to force an overwrite.

A duplicate workflow registration exits with status 2. CI should distinguish that from status 1, which indicates registration failure.

Release behavior

Before --mark-as-release:

  • Pin SDK, Python, system, and scientific dependencies.
  • Record tool and database versions.
  • Run a representative launch plan.
  • Confirm result links and metadata.
  • Verify the source commit is clean and reproducible.

Staging and Development Shell

Build an image without publishing a workflow version:

bash
latch register --staging .

Open a remote interactive shell in that image:

bash
latch develop .

Choose a development instance:

bash
latch develop . --instance-size small_gpu_task

Use latch develop --help to inspect the installed version's supported sizes.

Sync behavior

  • Local files under the workflow root are synced into the container.
  • Files outside that root are not synced.
  • Local updates overwrite corresponding container files.
  • Local deletions do not remove existing container files.
  • Container-side edits are not synced back and can be overwritten.
  • .gitignore and .dockerignore are respected.
  • Re-run staging registration after changing the Dockerfile or dependencies.

Place small test fixtures under the project root and exclude private or large data from registration archives.

Debug a Running Task

Open an interactive shell for an execution or task:

bash
latch exec --execution-id <execution-id>

For a Nextflow work directory:

bash
latch nextflow attach --execution-id <execution-id>

Use interactive access for diagnosis, not for modifying the source of record. Reproduce and fix the issue locally, then register a new version.

Programmatic Execution

The old latch launch CLI is deprecated. Use latch_cli.services.launch.launch_v2.

Launch with Python parameters

python
import asyncio

from latch.types import LatchFile
from latch_cli.services.launch.launch_v2 import launch

execution = launch(
    wf_name="my_workflow",
    version="1.2.3-abcd12",
    params={
        "reads": LatchFile("latch:///test-data/reads.fastq.gz"),
        "minimum_quality": 20,
    },
)

completed = asyncio.run(execution.wait())
if completed is None:
    raise RuntimeError("execution polling ended without a result")
if completed.status != "SUCCEEDED":
    raise RuntimeError(
        f"execution {completed.id} ended with {completed.status}"
    )

print(completed.output)
print([path.path for path in completed.ingress_data])

wf_name is the registered workflow name (check .latch/workflow_name or the Console), not the human-readable metadata display name.

launch defaults best_effort=True, allowing compatible dictionaries, dataclasses, strings for enum values, and other schema-guided conversions. Set best_effort=False only when the caller imports exactly the same Python types as the registered workflow.

Compatibility:

  • Programmatic launch requires workflows registered with SDK 2.62.0+.
  • Typed output decoding requires workflows registered with SDK 2.65.1+.
  • Python versions and imported classes must remain compatible for strict serialized type decoding.

Launch a registered launch plan

python
import asyncio

from latch_cli.services.launch.launch_v2 import launch_from_launch_plan

execution = launch_from_launch_plan(
    wf_name="my_workflow",
    version="1.2.3-abcd12",
    lp_name="Small public example",
)

completed = asyncio.run(execution.wait())
if completed is None or completed.status != "SUCCEEDED":
    raise RuntimeError("launch-plan execution did not succeed")

Poll or abort

Execution exposes:

  • id
  • status
  • poll()
  • async wait()
  • abort()

Abort only the intended active execution:

python
if execution.status not in {"SUCCEEDED", "FAILED", "ABORTED"}:
    execution.abort()

Interactive Execution Through MCP

When Latch MCP is available:

  1. List workspaces.
  2. List workflows.
  3. Fetch the selected workflow schema.
  4. Validate parameters.
  5. Obtain confirmation for paid compute.
  6. Launch.
  7. Poll execution state.
  8. Fetch task logs only for relevant failed or running nodes.

MCP authorization is separate from SDK login. See references/latch-mcp.md.

Monitoring

Console execution monitoring provides:

  • Overall execution status
  • Graph and task-node status
  • Inputs and outputs
  • Logs
  • Provenance and result files
  • Resource monitoring

The 2.76.8 CLI still provides the following deprecated command:

bash
latch get-executions

The official CLI guide says it will be removed in a future version. Prefer the Console or Latch MCP for new monitoring integrations.

For every production workflow, emit:

  • Concise message() calls for actionable warnings and errors
  • Result links for high-value outputs
  • Normal structured logs for detailed diagnostics

Do not log secrets or signed URLs.

Troubleshooting

Authentication failure

bash
latch login
latch workspace

Confirm the workspace is the one containing the data, workflow, and Registry objects. Do not attempt to repair authentication by modifying token files.

Registration cannot find the workflow

  • Confirm the workflow root and wf package.
  • Check --workflow-module.
  • Compile the Python package.
  • Verify metadata imports do not perform network calls.
  • Inspect task-specific Dockerfile arguments; they must be string literals.

Build failure

  • Reproduce through staging registration.
  • Use --docker-progress plain.
  • Check .dockerignore did not omit required files.
  • Confirm system packages and architecture.
  • Use --no-remote only when the local Docker environment is known-good.

Runtime import or executable failure

  • Enter latch develop.
  • Check which python3, installed packages, $PATH, and executable permissions.
  • Run the task-level test script inside the image.
  • Rebuild staging after dependency changes.

Out of memory or storage

  • Inspect resource monitoring.
  • Measure peak rather than average use.
  • Adjust one resource dimension at a time.
  • See references/resource-configuration.md.

Programmatic launch type error

  • Fetch the workflow's current schema/version.
  • Verify every required parameter.
  • Use best_effort=True for compatible external representations.
  • Re-register old workflows with a current SDK when typed outputs are needed.

Official Sources