Problem: Testing Temporal Workflows with Signals in Ruby SDK Time-Skipping Environment
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
wait_condition、customer_repliedシグナル、workflow_handle.resultを使用して、Temporalio::Testing::WorkflowEnvironment.start_time_skippingのワークフローを再現します。シグナルの配信と時間スキップによって実行がどのように再開されるかを追跡し、その後、start_workflowとexecute_workflowの動作を比較します。原因を特定し、検証済みのテスト方法または必要なSDKの変更を文書化できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Problem: Testing Temporal Workflows with Signals in Ruby SDK Time-Skipping Environment
Context
I'm testing a workflow in the Temporalio Ruby SDK that uses wait_condition to wait for signals. The workflow works correctly in production, but I cannot test the signal-driven continuation in the time-skipping test environment (Temporalio::Testing::WorkflowEnvironment.start_time_skipping).
Workflow Pattern (Simplified)
class PipelineExecutionWorkflow < Temporalio::Workflow
workflow_signal
def customer_replied
@customer_replied = true
end
def execute(opportunity_id, pipeline_id)
# Step 1: Send initial email
send_email_activity(opportunity_id)
# Step 2: Wait for customer reply signal
Temporalio::Workflow.timeout(48.hours) do
Temporalio::Workflow.wait_condition { @customer_replied }
end
# Step 3: Process customer reply (extract data, send AI response)
if @customer_replied
extract_and_respond(opportunity_id)
end
{ "success" => true }
end
end
What I've Tried in Tests
Temporalio::Testing::WorkflowEnvironment.start_time_skipping do |env|
worker = Temporalio::Worker.new(
client: env.client,
task_queue: "test-queue",
workflows: [PipelineExecutionWorkflow],
activities: [SendEmailActivity, ExtractActivity]
)
worker.run do
# Start workflow (doesn't wait for completion)
workflow_handle = env.client.start_workflow(
PipelineExecutionWorkflow,
opportunity_id,
pipeline_id,
id: "test-pipeline-#{opportunity_id}",
task_queue: "test-queue"
)
# Give time for initial email to be sent
sleep 0.5
# Check workflow state - shows it's waiting
state = workflow_handle.query("get_state")
# => {"waiting_for_signal" => true, "customer_replied" => false}
# Send the signal
workflow_handle.signal("customer_replied")
# Check state again - signal was received!
state_after = workflow_handle.query("get_state")
# => {"waiting_for_signal" => false, "customer_replied" => true}
# But when I try to get the result, it times out or returns nil
result = workflow_handle.result # ← TIMES OUT or returns nil
# The workflow doesn't continue executing after receiving the signal
end
end
Observed Behavior
- ✅ Workflow starts successfully
- ✅ Initial email activity executes
- ✅ Workflow enters wait state (
wait_condition) - ✅ Signal is received (verified via query -
@customer_repliedbecomestrue) - ❌ Workflow doesn't continue execution after signal received
- ❌
workflow_handle.resulttimes out or workflow appears "stuck"
Questions
With the Temporal Ruby SDK source code available:
-
Is this a known limitation of the time-skipping test environment with
wait_conditionand signals? -
What is the correct way to test workflows that use
wait_conditionwith signals in the time-skipping environment? -
Should I use a different testing approach for signal-driven workflows? (e.g., real Temporal server, different test helper methods)
-
Is there a way to manually advance time or "wake up" the workflow after sending a signal in the test environment?
-
Are there any special considerations or setup required for testing signal-driven workflows that use
wait_condition?
Additional Context
- Ruby SDK version: 1.0.0 (from Gemfile)
- The workflow works perfectly in production with real Temporal server
- Synchronous workflows (without signals/wait) test fine in time-skipping environment
- I've tried both
start_workflow(non-blocking) andexecute_workflow(blocking) - neither works for the signal continuation
- 主要言語
- Ruby
- スター
- 206
- フォーク
- 42
- 平均マージ
- 1日 48分
- マージ済み PR(30日)
- 16
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
temporalio/sdk-ruby のほかの issue
-
[Bug] Fiber activity executor: cancelling an activity permanently strands the poller under a fiber scheduler対応中かも @GregoryTravis が 19 日前に担当しました。 オープン
temporalio/sdk-ruby#570 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
[Feature Request] Add thread lifecycle hook to `Worker::ThreadPool`再び着手できるかも @GregoryTravis が 33 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンenhancement
temporalio/sdk-ruby#563 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
[Feature Request] Implement operator commands for Standalone Activities再び着手できるかも @GregoryTravis が 83 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンenhancement
temporalio/sdk-ruby#440 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
temporalio/sdk-ruby#401 ·
メンテナーはふだん 2 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
temporalio/sdk-ruby#393 ·
メンテナーはふだん 2 日以内に返信
temporalio/sdk-ruby の issue をすべて見る
似ている issue
-
P2 testing
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
メンテナーはふだん 1 日以内に返信
-
performance
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
openSUSE/open-build-service#20338 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
バグ
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信