Add chasm standby task verification by yux0 · Pull Request #12618 · temporalio/temporal · GitHub
Skip to content

Add chasm standby task verification - #12618

Draft
yux0 wants to merge 1 commit into
mainfrom
yx/chasm-standby-verification
Draft

yux0 wants to merge 1 commit into
mainfrom
yx/chasm-standby-verification

Conversation

@yux0

@yux0 yux0 commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

What changed?

This change separates active and standby validation for CHASM side effect tasks.

Why?

Today, both active and standby paths called Validate, requiring one function to decide whether a task should execute on active and whether it is still pending on standby. These decisions can require different rules: an active validator may stop retrying after an attempt threshold, while standby should continue waiting for the active cluster’s progress to replicate.

How did you test it?

  • built
  • run locally and tested manually
  • covered by existing tests
  • added new unit test(s)
  • added new functional test(s)

@yux0 yux0 added the team/cgs-foundation Require cgs foundation team review label Oct 19, 2026
@yux0
yux0 added this pull request to stack #12634 October 20, 2026 17:07
Comment thread chasm/task.go

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to support RPC calls in standby validator right? I think that's the main purpose of the separate validator. If validation can be done just be checking component state then existing task Validate() method already covers it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume RPC calls for internal temporal? We can have a offline sync on this.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal temporal

for the cases I am aware of yes, usually talk to a different execution. Main thing is we shouldn't keep the execution locked when the RPC is happening. I know for parent/child we hold the lock, but ideally we don't do that?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team/cgs-foundation Require cgs foundation team review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants