ReviewOS

stacks/ts-cloud

Add a durable deployment queue with live logs, cancellation, retries, and concurrency controls

#148
Closed chris opened this 2 months ago ·
2 months ago

Roadmap relationship

Outcome

Run deployments and other long-lived mutations as durable background operations with ordered events, streaming output, explicit concurrency, safe cancellation, retries, and recovery after process restarts.

Current gap

Dashboard actions currently spawn CLI processes inside requests, while deployments across server/serverless/container paths have separate progress/history models. There is no persisted queue, resource lock, retry policy, queue visibility, or robust distinction between cancelling queued work and interrupting a provider operation.

User experience

  • Show global and scoped queue views with status, target, actor/trigger, commit, priority, queued/start/duration times, attempt, and current step.
  • Deployment detail streams ordered structured steps plus raw expandable logs, reconnects from a cursor, and clearly marks redacted/truncated content.
  • Allow cancel queued, request cancellation of running work, retry failed/cancelled work, and clear completed history according to retention policy.
  • Display why work is blocked (concurrency, dependency, resource lock, maintenance) and its estimated position without fake precision.

Scope

  • Create persistent queue/lease/worker primitives using the operation/event schema.
  • Add per-project, environment, server/provider, and build concurrency controls with configurable defaults.
  • Define step checkpoints, heartbeats, timeouts, cancellation tokens, retry/backoff, idempotency, and orphan reconciliation.
  • Adapt server, serverless, static, and container deployment entry points to enqueue shared jobs.
  • Provide authenticated Server-Sent Events or WebSocket progress with cursor resume and polling fallback.
  • Add queue management CLI/API/dashboard surfaces and deployment retention.

Technical direction

  • Use transactional claim/lease semantics and resource-scoped locks to prevent conflicting deploy/destroy/restore work.
  • Separate job orchestration from provider driver calls; drivers report structured progress and declare cancellability.
  • Persist sanitized stdout/stderr chunks with sequence numbers and bounded storage.
  • Propagate request, operation, deployment, provider, and audit correlation IDs.

Safety and operability

  • Retries must be opt-in by error class and never blindly repeat destructive non-idempotent steps.
  • Cancellation records what finished, what could not be cancelled, and required reconciliation.
  • Secrets are redacted before persistence/streaming; log authorization matches target resource permission.
  • Production concurrency and queue-clearing changes require elevated permission and audit.

Acceptance criteria

  • A queued deployment survives dashboard restart and either resumes safely or ends in an explicit recoverable state.
  • Conflicting operations on the same target cannot run concurrently.
  • A disconnected browser resumes log streaming without gaps or duplicate visible entries.
  • Cancel, retry, timeout, and provider failure produce deterministic terminal states and audit records.

Verification

  • Lease expiry, duplicate worker, crash/restart, ordering, lock, retry, timeout, cancellation, and cursor-resume tests.
  • Secret redaction and authorization tests for persisted and streamed logs.
  • End-to-end concurrent deploy, restart-mid-deploy, cancel, and retry scenarios.

Non-goals

  • Distributed multi-region queue workers in the first release.
  • Claiming provider operations are cancellable when their API is not.
  • Replacing CI provider job queues outside ts-cloud.
8 days ago

Implemented top-to-bottom on main in small conventional commits.

Delivered:

  • persistent schema-backed jobs, leases, heartbeats, resource locks, checkpoints, ordered bounded logs, cursor reads, redaction, cancellation, timeouts, retry allow-lists/backoff, orphan recovery, retention, and configurable project/environment/provider/build concurrency
  • deployment, rollback, application onboarding, source-push, and preview producers routed through the shared queue
  • bounded parallel dashboard worker lanes that execute the existing deployment pipeline, stream stdout/stderr incrementally, terminate cooperative child processes on cancellation, classify transient failures, and drain safely on shutdown
  • authenticated v1 queue/settings/history/log/SSE/cancel/retry API, OpenAPI contract, and typed client
  • queue CLI management and an authorized responsive dashboard console with structured steps, raw logs, reconnect deduplication, blocking reasons, cancellation, retry, settings, and retention controls
  • operator documentation covering lifecycle, safety, recovery, permissions, API, CLI, and retention

Key commits:

  • d181a5c durable orchestration primitives
  • ade6ffe durable deployment producers
  • 4b3a822 queue API and typed client
  • e49a3da queue CLI
  • 0b245da live queue dashboard
  • c714903 bounded durable workers
  • 4782633 scoped deployment handlers
  • 748b567 streamed deployment worker execution
  • 3e3de3d operator documentation

Verification:

  • bun test: 2,620 pass, 0 fail, 2 skip, 2 todo; 7,174 assertions across 351 files
  • bunx tsc --noEmit -p packages/ts-cloud/tsconfig.json: clean
  • dashboard build: 43/43 routes
  • docs build: 35 pages
  • focused end-to-end coverage proves enqueue -> transactional claim -> child-process execution -> streamed stdout/stderr -> persisted successful terminal state; restart, duplicate-worker, lock, cursor, redaction, truncation, retry, cancellation, and timeout paths are covered as well.

Sign in to comment on this issue.