Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Feature: Non-blocking signal and update handlers

Đang mở
  • Có gì không ổn?
#489 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
go, yaml
Lĩnh vực
backend, distributed-systems

Hướng nghiên cứu

Bắt đầu bằng cách lần theo entry point listen hiện có và hành vi Continue-As-New của runtime. So sánh cú pháp YAML handlers được đề xuất với các câu hỏi thiết kế còn bỏ ngỏ, sau đó sử dụng các tiêu chí chấp nhận đã nêu và yêu cầu về độ bao phủ E2E để xác định khi nào các signal không chặn, các bản cập nhật, khả năng hiển thị state và khả năng tồn tại của handler đã hoàn tất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement go good first issue never-stale v1

Summary

Add support for non-blocking signal and update handlers.

Today, listen is intentionally blocking:

  • query registers a handler and continues execution
  • signal blocks until a matching signal is received
  • update blocks until a matching update is received

This works well for approval workflows and other wait-for-event patterns, but makes it difficult to model long-running entity-style workflows that must continue executing while still accepting external messages.

Motivation

Temporal supports message handlers that can execute independently of the main workflow path.

Examples:

  • Order workflow

    • Signal: cancel order
    • Signal: change shipping address
    • Query: current status

  • Subscription workflow

    • Signal: pause subscription
    • Signal: resume subscription
    • Update: change plan
    • Query: billing status

  • Batch processing workflow

    • Signal: increase concurrency
    • Signal: stop after current batch
    • Update: add more work
    • Query: current progress

In these scenarios, the workflow should continue running while remaining responsive to external messages.

Currently, Zigflow users must model signals and updates as explicit blocking steps in the workflow, which prevents this style of workflow.

Proposed design

Introduce a dedicated non-blocking message handler construct rather than extending the semantics of listen.

Example:

handlers:
  signals:
    cancel:
      set:
        cancelled: true

  updates:
    setPriority:
      set:
        priority: ${ .priority }

Alternative syntaxes are possible.

The important behaviour is:

  • Handlers are registered when the workflow starts
  • Handlers remain active for the lifetime of the workflow
  • Handlers do not block workflow execution
  • Handlers may modify workflow state
  • Queries can observe state modified by handlers

Continue-As-New considerations

Non-blocking handlers must survive Continue-As-New.

The runtime should:

  • Re-register handlers on the continued execution
  • Preserve any state mutations made by handlers
  • Continue routing signals and updates addressed to the Workflow ID

Open questions

  • Should handlers be allowed to execute activities?
  • Should handlers be allowed to mutate $context, $data, or both?
  • Should handlers be able to return values directly (update-style responses)?
  • What concurrency guarantees should exist when handlers and workflow execution modify the same state?
  • Should handler definitions be a new top-level section (handlers) or an extension of listen?

Acceptance criteria

  • Users can define non-blocking signal handlers
  • Users can define non-blocking update handlers
  • Workflow execution continues while handlers remain active
  • Handler state changes are visible to queries
  • Handlers survive Continue-As-New
  • Documentation and examples are provided
  • E2E tests cover signal, update and Continue-As-New behaviour
Ngôn ngữ chính
Go
Star
209
Fork
27
Merge trung bình
6 giờ 35 phút
Pull request đã merge (30 ngày)
30

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của zigflow/zigflow

Tất cả issue của zigflow/zigflow

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.