diff --git a/lib/temporal/configuration.rb b/lib/temporal/configuration.rb index 828c561f..8d36615c 100644 --- a/lib/temporal/configuration.rb +++ b/lib/temporal/configuration.rb @@ -14,6 +14,7 @@ class Configuration attr_writer :converter attr_accessor :connection_type, :host, :port, :logger, :metrics_adapter, :namespace, :task_queue, :headers + # See https://docs.temporal.io/blog/activity-timeouts/ for general docs. # We want an infinite execution timeout for cron schedules and other perpetual workflows. # We choose an 10-year execution timeout because that's the maximum the cassandra DB supports, # matching the go SDK, see https://github.com/temporalio/sdk-go/blob/d96130dad3d2bc189bc7626543bd5911cc07ff6d/internal/internal_workflow_testsuite.go#L68 @@ -21,9 +22,12 @@ class Configuration execution: 86_400 * 365 * 10, # End-to-end workflow time, including all recurrences if it's scheduled. # Time for a single run, excluding retries. Server defaults to execution timeout; we default here as well to be explicit. run: 86_400 * 365 * 10, - task: 10, # Workflow task processing time + # Workflow task processing time. Workflows should not use the network and should execute very quickly. + task: 10, schedule_to_close: nil, # End-to-end activity time (default: schedule_to_start + start_to_close) - schedule_to_start: 10, # Queue time for an activity + # Max queue time for an activity. Default: none. This is dangerous; most teams don't use. + # See # https://docs.temporal.io/blog/activity-timeouts/#schedule-to-start-timeout + schedule_to_start: nil, start_to_close: 30, # Time spent processing an activity heartbeat: nil # Max time between heartbeats (off by default) }.freeze diff --git a/spec/unit/lib/temporal/configuration_spec.rb b/spec/unit/lib/temporal/configuration_spec.rb new file mode 100644 index 00000000..7e083429 --- /dev/null +++ b/spec/unit/lib/temporal/configuration_spec.rb @@ -0,0 +1,29 @@ +require 'temporal/configuration' + +describe Temporal::Configuration do + describe '#initialize' do + it 'initializes proper default workflow timeouts' do + timeouts = subject.timeouts + + # By default, we don't ever want to timeout workflows, because workflows "always succeed" and + # they may be long-running + expect(timeouts[:execution]).to be >= 86_400 * 365 * 10 + expect(timeouts[:run]).to eq(timeouts[:execution]) + expect(timeouts[:task]).to eq(10) + end + + it 'initializes proper default activity timeouts' do + timeouts = subject.timeouts + + # Schedule to start timeouts are dangerous because there is no retry. + # https://docs.temporal.io/blog/activity-timeouts/#schedule-to-start-timeout recommends to use them rarely + expect(timeouts[:schedule_to_start]).to be(nil) + # We keep retrying until the workflow times out, by default + expect(timeouts[:schedule_to_close]).to be(nil) + # Activity invocations should be short-lived by default so they can be retried relatively quickly + expect(timeouts[:start_to_close]).to eq(30) + # No heartbeating for a default (short-lived) activity + expect(timeouts[:heartbeat]).to be(nil) + end + end +end \ No newline at end of file