Pass fork context into the created task

When POST /fork is used with an afterSeq (including the CLI flow with orka task fork --after ... --prompt ...), this only replaces the task prompt with the caller text; the computed forkCtx is returned after the Task is already created and only summarized in annotations, and no worker path reads those fork annotations. The forked task therefore has neither the selected checkpoint events nor a workspace snapshot, so it cannot actually continue from the requested event sequence; include the bounded fork context in the created Task's worker-visible context before creation.

Useful? React with 👍 / 👎.

Keep approval IDs outside truncatable reason payloads

When an approval decision includes a large reason (large enough to push this JSON over MaxExecutionEventContentJSONBytes), the store sanitization replaces the whole content object with a truncated marker before persistence. For approval requests that only carry approvalID and no ToolCallID (which the API/tests allow), approvals.Derive can no longer associate the terminal decision with the pending approval, so the decision response can be empty and the approval remains pending. Bound the reason separately or store the decision identity in fields that survive content truncation.

Useful? React with 👍 / 👎.

Clear schedules when creating fork tasks

When the source task is a scheduled task, this full spec copy preserves spec.schedule (and related scheduling fields) on the fork. The controller checks task.Spec.Schedule in the pending phase before creating a Job, so a checkpoint fork of a scheduled source is moved back onto the cron schedule instead of running the requested fork once, and it may repeat later as a scheduled task. Clear scheduling fields for forked tasks unless the request explicitly asks for a scheduled fork.

Useful? React with 👍 / 👎.

Requeue when terminal event recording fails

When the event store transiently rejects the terminal lifecycle append, this helper only logs the failure. completeTask gets one later retry via handleCompleted, but handleCompleted also swallows the append error and can return without requeueing, leaving a terminal Task with no TaskSucceeded/TaskFailed/TaskCancelled event. Since task SSE completion is driven by those terminal events rather than task status, followers can remain open indefinitely after the store recovers; surface the failure from the terminal path or requeue until the terminal event is persisted.

Useful? React with 👍 / 👎.

Don't document terminal approvals as worker events

This list tells worker authors they can submit terminal approval events, but SubmitExecutionEvent rejects ApprovalApproved, ApprovalDeclined, ApprovalExpired, and ApprovalCancelled as worker terminal events with 403; only ApprovalRequested is worker-emittable, while decisions go through the approval decision API. Following this reference will make worker integrations fail as soon as they try to report a decision or expiry.

Useful? React with 👍 / 👎.

Treat interrupted follows as a clean exit

When a user stops orka task follow or orka session follow with Ctrl-C/SIGTERM, ctx.Err() is set and the SSE scanner commonly reports context canceled; this branch prints the resume cursor but then returns reader.Err(), so Cobra still exits with an error for the normal stop path. The existing chat/log streaming paths suppress stream errors once the signal context is canceled, and this follow command should do the same after printing the resume hint.

Useful? React with 👍 / 👎.

Force worker events to use the routed task name

When a worker includes a non-empty taskName that differs from the streamID in this internal route, this only fills the field when it is missing and never overwrites or rejects the spoofed value. The writer check proves the caller owns streamID, but session timelines and event DTOs display event.TaskName, so a buggy worker for task A can persist rows attributed to task B; derive TaskName from the route just like SessionName is derived from the Task.

Useful? React with 👍 / 👎.

Reject explicit negative fork checkpoints

When a user runs orka task fork --after -5, Cobra records the negative value but this sentinel check treats every negative after as if the flag were omitted, so the request body leaves out afterSeq and the server forks from the latest event instead of returning its non-negative afterSeq validation error. Distinguish the default sentinel from an explicitly changed flag, otherwise a mistyped checkpoint can create a fork from the wrong point in the timeline.

Useful? React with 👍 / 👎.

Emit artifact events from general workers

When a general worker writes files under /tmp/artifacts, submitResult calls UploadArtifacts() before this ResultSubmitted event is recorded, but this path never emits ArtifactUploadCompleted or ArtifactUploadFailed. As a result, successful uploads from general/container tasks are missing from task trace (which only populates artifacts from those event types), and if artifact upload fails after the result was submitted, the timeline shows only a worker failure with no result or artifact-upload event explaining what happened.

Useful? React with 👍 / 👎.

Bound fork context before embedding in Task specs

When forking a long task whose recent events include large contentText or JSON payloads, this marshals the whole bounded-by-count fork context directly into the new Task prompt. Since each event can still carry tens of KiB after redaction/truncation and up to 200 events are included, the generated Task object can become multi-MiB and be rejected by the Kubernetes API, making POST /fork fail for exactly the long traces this checkpoint path targets; apply a byte budget or summarize before writing the context into the spec.

Useful? React with 👍 / 👎.

Index session streams by their session cursor

This index is keyed by the per-task seq, but the session APIs page and order by the derived session_seq/effective_session_seq cursor in ListSessionExecutionEvents. For long-lived sessions, every orka session follow poll with a high after cursor still has to scan the session's historical rows to compute/list later session events instead of seeking to the cursor, so idle followers become O(total session events); add an index on the session cursor (and type if needed) or use the maintained cursor table for latest-seq reads.

Useful? React with 👍 / 👎.