[zzkamzn]

Problem

PipelineService.get_run looked for the id among the 50 newest runs, across every pipeline (list_runs(limit=50)). Once 50 more runs had started:

• GET /api/v1/pipeline-runs/{id} returned 404 for a run that exists.
• run_sync found nothing, so it reported ok: false for a run that had completed. run_sync is the path used by the scheduler and by a script's nested workflow() call.

On a deployment with a few frequent schedules, 50 runs is a matter of hours.

run_sync also reads the final status immediately after writing it, using an eventually consistent Query. That can return the earlier running item.

Change

• _create_run also writes a pointer item PK=PIPELINERUN#<run_id>, SK=META holding the run's sort key.
• get_run reads the pointer, then the run, so lookup no longer depends on how many runs came after.
• Runs created before this change have no pointer and are still found in the recent window as before.
• start_run and run_sync already know the sort key, so they read the run directly with a strongly consistent GetItem.

There are no schema, Terraform or API changes. The pointer item is about 100 bytes per run.

Test plan

• New backend/tests/test_pipeline_runs.py, 3 tests:
  • A run is found by id after 60 newer runs.
  • run_sync reports ok from a consistent read of the final status.
  • A run without a pointer is still found.
• ruff reports no new findings. The two existing findings in pipeline_service.py are unchanged from main.

This came out of an inventory of DynamoDB access patterns done for the #44 review. It is independent of #44.

🤖 Generated with Claude Code

[odinwang]

Thanks! This change is included in #66 (published together with the related platform fixes). This repository is now updated by snapshot PRs only, so closing this one.