Documentation
¶
Index ¶
- Constants
- type AppendStepRequest
- type AppendStepResponse
- type ApproveStepRequest
- type ApproveStepResponse
- type CancelGroupRequest
- type CancelGroupResponse
- type CancelStepRequest
- type CancelStepResponse
- type CancelWorkflowResponse
- type IsRetryableResponse
- type PollNextStepResponse
- type RetryGroupRequest
- type RetryGroupResponse
- type RetryStepRequest
- type RetryStepResponse
- type Signal
- func (s *Signal) AutoExecuteOnTerminalStart() bool
- func (s *Signal) Cancel(ctx workflow.Context) error
- func (s *Signal) Execute(ctx workflow.Context) error
- func (s *Signal) LifecycleContext() qsignal.SignalLifecycleContext
- func (s *Signal) RegisterUpdateHandlers(ctx workflow.Context) error
- func (s *Signal) SleepAfter() time.Duration
- func (s *Signal) Type() qsignal.SignalType
- func (s *Signal) Validate(ctx workflow.Context) error
- func (s *Signal) WithParams(p *qsignal.Params)
- type SkipStepRequest
- type SkipStepResponse
Constants ¶
const SignalType qsignal.SignalType = "execute-workflow"
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type AppendStepRequest ¶ added in v0.19.1024
type AppendStepRequest struct {
Name string `json:"name"`
Signal signaldb.SignalData `json:"signal"`
ExecutionType app.WorkflowStepExecutionType `json:"execution_type,omitempty"`
// StepTargetType / StepTargetID identify the work this step drives (e.g. an
// the inner signal's target row). StepTargetID also
// serves as the append idempotency key: a retried append (Temporal update
// retry or HTTP retry) with the same StepTargetID returns the existing
// group/step instead of creating a duplicate.
StepTargetType string `json:"step_target_type,omitempty"`
StepTargetID string `json:"step_target_id,omitempty"`
Retryable bool `json:"retryable,omitempty"`
Skippable bool `json:"skippable,omitempty"`
}
AppendStepRequest is the input for the "append-step" update handler. It adds a new single-step group to a parked Resident workflow (e.g. an appended step) and wakes the execute loop to run only that step.
The caller builds the step metadata (execution type, target type) the same way installSignalStep does — this keeps the low-level flow package free of the installs signal taxonomy. Queue IDs are intentionally left empty: dispatch resolves the target queue from the signal, exactly like the adhoc-action path.
type AppendStepResponse ¶ added in v0.19.1024
type AppendStepResponse struct {
WorkflowID string `json:"workflow_id"`
GroupID string `json:"group_id"`
StepID string `json:"step_id"`
}
AppendStepResponse reports the IDs of the freshly-created group and step so the caller (e.g. a appended step run) can track the appended work.
type ApproveStepRequest ¶
type ApproveStepRequest struct {
StepID string `json:"step_id"`
ApprovalResponseID string `json:"approval_response_id"`
ResponseType string `json:"response_type"`
}
ApproveStepRequest is the input for the "approve-step" update handler.
type ApproveStepResponse ¶
type ApproveStepResponse struct {
WorkflowID string `json:"workflow_id"`
}
ApproveStepResponse is the response from the "approve-step" update handler.
type CancelGroupRequest ¶
type CancelGroupRequest struct {
// StepID is any step in the group to cancel. The handler resolves the
// group from this step's GroupIdx and cancels all in-flight steps.
StepID string `json:"step_id"`
}
CancelGroupRequest is the input for the "cancel-group" update handler.
type CancelGroupResponse ¶
type CancelGroupResponse struct {
WorkflowID string `json:"workflow_id"`
}
CancelGroupResponse is the response from the "cancel-group" update handler.
type CancelStepRequest ¶
type CancelStepRequest struct {
StepID string `json:"step_id"`
}
CancelStepRequest is the input for the "cancel-step" update handler.
type CancelStepResponse ¶
type CancelStepResponse struct {
WorkflowID string `json:"workflow_id"`
}
CancelStepResponse is the response from the "cancel-step" update handler.
type CancelWorkflowResponse ¶
type CancelWorkflowResponse struct {
WorkflowID string `json:"workflow_id"`
}
CancelWorkflowResponse is the response from the "cancel-workflow" update handler.
type IsRetryableResponse ¶
type IsRetryableResponse struct {
Retryable bool `json:"retryable"`
StepID string `json:"step_id"`
}
IsRetryableResponse is the response from the "is-retryable" update handler.
type PollNextStepResponse ¶
type PollNextStepResponse struct {
StepID string `json:"step_id"`
StepIdx int `json:"step_idx"`
Status app.Status `json:"status"`
}
PollNextStepResponse is the response from the "poll-next-step" update handler.
type RetryGroupRequest ¶
type RetryGroupRequest struct {
// StepID is any step in the group to retry. The handler resolves the
// group from this step's GroupIdx.
StepID string `json:"step_id"`
}
RetryGroupRequest is the input for the "retry-group" update handler.
type RetryGroupResponse ¶
type RetryGroupResponse struct {
WorkflowID string `json:"workflow_id"`
Retryable bool `json:"retryable"`
}
RetryGroupResponse is the response from the "retry-group" update handler.
type RetryStepRequest ¶
type RetryStepRequest struct {
StepID string `json:"step_id"`
}
RetryStepRequest is the input for the "retry-step" update handler.
type RetryStepResponse ¶
type RetryStepResponse struct {
WorkflowID string `json:"workflow_id"`
Retryable bool `json:"retryable"`
}
RetryStepResponse is the response from the "retry-step" update handler.
type Signal ¶
type Signal struct {
// WorkflowID is the ID of the workflow to execute.
WorkflowID string `json:"workflow_id"`
// WorkflowType / OrgID / OrgName are resolved during Validate() from the
// in-scope workflow record so the lifecycle hook can emit workflow.lifecycle
// events without a fresh DB lookup. Empty until Validate runs.
WorkflowType string `json:"workflow_type,omitempty"`
OrgID string `json:"org_id,omitempty"`
OrgName string `json:"org_name,omitempty"`
// Conductor configuration — set by the creator when enqueuing.
StepGroupQueueName string `json:"step_group_queue_name"`
StepQueueName string `json:"step_queue_name"`
StepTargetQueueName string `json:"step_target_queue_name"`
GenerateStepsQueueName string `json:"generate_steps_queue_name"`
OwnerID string `json:"owner_id"`
OwnerType string `json:"owner_type"`
// OwnerName is the human-readable owner label resolved during Validate()
// (e.g. install/app/app_branch name). Stamped onto SignalLifecycleContext
// so workflow lifecycle webhook payloads carry owner_name without a
// per-event DB lookup.
OwnerName string `json:"owner_name,omitempty"`
// Resident keeps the workflow alive after it runs 0->end: instead of
// completing, the execute loop parks to accept run-a-step-in-between
// updates (append/retry a step). Gated so ordinary workflows keep exact
// run-to-completion semantics. Bounded by residentIdleTimeout — on idle
// the loop returns cleanly and the workflow re-warms on the next dispatch.
Resident bool `json:"resident,omitempty"`
// contains filtered or unexported fields
}
func (*Signal) AutoExecuteOnTerminalStart ¶ added in v0.19.1024
AutoExecuteOnTerminalStart re-enters Execute when a resident host is (re)started by update-with-start after it idled out and completed. See the queue handler's re-warm path.
func (*Signal) Cancel ¶ added in v0.19.934
Cancel is invoked by the queue handler when the signal is cancelled externally (e.g. via clear-queue). It marks the underlying workflow object as cancelled so the install workflow doesn't stay in a stale in-progress state.
func (*Signal) LifecycleContext ¶ added in v0.19.915
func (s *Signal) LifecycleContext() qsignal.SignalLifecycleContext
LifecycleContext exposes the workflow identity + owner so lifecycle hooks can emit workflow.lifecycle.* webhook events without leaking inner-signal taxonomy. Workflow type and org id are stamped during Validate from the in-scope workflow record.
func (*Signal) RegisterUpdateHandlers ¶
func (*Signal) SleepAfter ¶
SleepAfter caches a finished non-resident Handler briefly so a follow-up signal can reuse it via update-with-start. A resident host returns 0: once its Execute() returns the conductor loop is gone, so keeping the Handler alive would let an append-step/retry-step land on a finished run that can never consume it — the re-warm path (AutoExecuteOnTerminalStart) handles reuse instead.
func (*Signal) Type ¶
func (s *Signal) Type() qsignal.SignalType
func (*Signal) WithParams ¶ added in v0.19.981
type SkipStepRequest ¶
type SkipStepRequest struct {
StepID string `json:"step_id"`
}
SkipStepRequest is the input for the "skip-step" update handler.
type SkipStepResponse ¶
type SkipStepResponse struct {
WorkflowID string `json:"workflow_id"`
Skippable bool `json:"skippable"`
}
SkipStepResponse is the response from the "skip-step" update handler.
Source Files
¶
- clone_group.go
- execute.go
- execute_group.go
- init.go
- signal.go
- update_append_step.go
- update_approve_step.go
- update_cancel_group.go
- update_cancel_step.go
- update_cancel_workflow.go
- update_is_retryable.go
- update_pause.go
- update_poll_next_step.go
- update_retry_group.go
- update_retry_step.go
- update_skip_step.go
- update_unpause.go