Jobs and WatchJob
Availability: The DevBase runtime and production API are not yet deployed. This page describes the committed v1 contract for integration planning; requests to the API URL will not succeed until the runtime is released.
Asynchronous mini-app operations return a Job in queued, running, canceling, succeeded, failed, or canceled state. Jobs include progress, attempts, retry timing, terminal errors, input artifacts, result artifacts, and a resource version.
Cancellation is best effort: queued work cancels immediately; running work may finish a non-interruptible step first. Replaying a failed request ID returns the same failed Job; use a new request ID for an intentional rerun.
WatchJob is server-streaming. Pass afterResourceVersion to resume from the last snapshot. The stream emits newer Job snapshots and a heartbeat every 30 seconds. It does not promise permanent event replay or ordering across independent Jobs, so clients should reconnect and reconcile with GetJob.
Repository applications use the private SDK's bounded reconnect helper. It resumes from the greatest Job or heartbeat version received and retries only transient transport failures or normal stream expiry, at most five times with approximately 1, 2, 4, 8, and 16 second backoff. Any event resets that consecutive-failure count. Authentication or permission failure, a missing Job, caller cancellation, and a terminal Job stop the watch. After retries are exhausted, reconcile with GetJob before starting a new watch. This behavior does not re-run execution-stream RPCs.