Turn off schedule_to_start activity timeout by default

lib/temporal/configuration.rb

@@ -14,16 +14,20 @@ 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
     DEFAULT_TIMEOUTS = {
       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

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