Skip to content

feat(gcp-cloud-run): live chunk-level render progress via the step-entries API#1904

Open
HackingCorp wants to merge 1 commit into
heygen-com:mainfrom
HackingCorp:feat/gcp-midflight-progress
Open

feat(gcp-cloud-run): live chunk-level render progress via the step-entries API#1904
HackingCorp wants to merge 1 commit into
heygen-com:mainfrom
HackingCorp:feat/gcp-midflight-progress

Conversation

@HackingCorp

Copy link
Copy Markdown

Summary

Closes the biggest observability gap between the GCP and AWS adapters: getRenderProgress reported overallProgress = 0 for the whole life of an ACTIVE execution (the basic Executions API exposes no per-step data), while the Lambda adapter reads Step Functions history and shows live progress. Adopters couldn't render a progress bar on GCP.

Changes

  • getRenderProgress now reads the Cloud Workflows step-entries API (executions.stepEntries.list) while the execution is ACTIVE. The @google-cloud/workflows gapic client (v4) has no surface for it yet, so the default reader hits the REST endpoint with ADC via google-auth-library (new direct dependency; already in the transitive graph). Injection seam (stepEntries) mirrors the existing executions seam for tests.
  • overallProgress follows the same 10% plan + 80% chunks + 10% assemble split as the AWS adapter — measured in chunks instead of frames, since step entries carry no payloads. New chunksCompleted / totalChunks fields expose the raw counts (framesRendered stays 0 until success, as before).
  • The appendSlots succeeded-entry count doubles as the planned chunk total — available right after buildChunkList, well before any chunk finishes.
  • Best-effort by design: a caller lacking workflowexecutions.stepEntries.list (part of roles/workflows.viewer), an older control plane, or a transient error degrades to the previous coarse snapshot instead of failing the poll. midFlightProgress: false skips the extra API call entirely.
  • hyperframes cloudrun progress and render --wait print the chunk counts; docs updated.

No workflow.yaml or Terraform changes required.

Testing

  • 11 unit tests on getRenderProgress (mid-flight math, plan-only phase, assemble cap at 0.99, permission-failure degradation, opt-out, success-path chunk fields), full packages/gcp-cloud-run suite green (68 tests).
  • packages/gcp-cloud-run + packages/cli typecheck clean on top of current main.

🤖 Generated with Claude Code

https://claude.ai/code/session_018TXJXMe4QmSBnmYoR3brtk

…tries API

getRenderProgress reported overallProgress=0 until the execution
succeeded, because the basic Executions API exposes no per-step data.
This reads executions.stepEntries.list (REST — the gapic client has no
surface for it yet) while the execution is ACTIVE and reports
overallProgress on the same 10% plan + 80% chunks + 10% assemble split
as the AWS adapter, plus new chunksCompleted/totalChunks fields. The
appendSlots succeeded-entry count doubles as the planned chunk total
before any chunk finishes. Best-effort: a missing
workflowexecutions.stepEntries.list permission (part of
roles/workflows.viewer) degrades to the old coarse snapshot;
midFlightProgress:false skips the extra call per poll. CLI progress +
--wait now print chunk counts.
HackingCorp added a commit to HackingCorp/ltc-motion that referenced this pull request Jul 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant