Clarify Standalone Activity start Action counting

[tekkaya]

What does this PR do?

Clarifies in the Temporal Cloud Actions reference (docs/evaluate/temporal-cloud/actions.mdx, Activity section) that a Start Standalone Activity request which returns an already-running Activity (de-duplicated by Activity ID) does not count as an Action — unless the start request tries to attach a callback to the running Activity, for example within a Nexus handler using the USE_EXISTING conflict policy.

[CLAassistant]

All committers have signed the CLA.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
temporal-documentation	Ready	Preview	Aug 20, 2026 7:40pm

[github-actions]

📖 Docs PR preview links

• Cloud
  • Actions

[bergundy]

"Conflict options" isn't a concept that is exposed to users. It'd be better to phrase it as "unless the start request tries to attach a callback to a running execution, for example when used within a Nexus handler with USE_EXISTING conflict policy".

[tekkaya]

what is the current status of the related changes in temporal cloud, is it time to merge this change?

[jsundai]

https://github.com/temporalio/saas-temporal/pull/7603

[jsundai]

@tekkaya Checking in on this! Is this ready for review?

[tekkaya]

@tekkaya Checking in on this! Is this ready for review?

When I check the temporal cloud there is still one ring (101) which is not including this change (running on oss1.32.0_156.6). The change is included starting from version oss1.32.0-157.2 All other rings have this update deployed.

[Copilot]

Pull request overview

Clarifies how Temporal Cloud counts Standalone Activity start Actions.

Changes:

• Documents deduplicated start behavior and the callback exception.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Opengrep — new findings

Severity	Location	Rule	Message
WARNING	.github/workflows/update-sdk-versions.yml:19	security.gha.unpinned-action	Unpinned action reference actions/create-github-app-token@v3: this uses: resolves a mutable ref (tag or branch), so the code that runs in CI can change without this line changing. A compromised upstream can repoint the tag and execute arbitrary code with access to this repository's secrets and GITHUB_TOKEN (tj-actions/changed-files, March 2025). Pin to the full 40-character commit SHA with the resolved version in a trailing comment, e.g. uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2. Prefer deputy pin --ecosystems github-actions, which resolves the ref, writes a version comment that reflects the most specific ref actually pointing at that commit, and verifies the SHA is reachable from a real branch upstream. That last check matters: pinning alone does not detect imposter or dangling commits, and this rule only sees the shape of the ref, never its provenance. Reusable workflow calls (owner/repo/.github/workflows/x.yml@ref) run with the same trust as actions and are pinned the same way. Not reported, by campaign policy: temporalio/* refs (first-party, pinned by internal process), local ./ actions, self-repository $/ refs (resolve to the running commit, so they are already pin-equivalent), and docker:// images (pinned by digest as a separate ecosystem).
WARNING	.github/workflows/update-sdk-versions.yml:31	security.gha.unpinned-action	Unpinned action reference actions/setup-node@v7.0.0: this uses: resolves a mutable ref (tag or branch), so the code that runs in CI can change without this line changing. A compromised upstream can repoint the tag and execute arbitrary code with access to this repository's secrets and GITHUB_TOKEN (tj-actions/changed-files, March 2025). Pin to the full 40-character commit SHA with the resolved version in a trailing comment, e.g. uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2. Prefer deputy pin --ecosystems github-actions, which resolves the ref, writes a version comment that reflects the most specific ref actually pointing at that commit, and verifies the SHA is reachable from a real branch upstream. That last check matters: pinning alone does not detect imposter or dangling commits, and this rule only sees the shape of the ref, never its provenance. Reusable workflow calls (owner/repo/.github/workflows/x.yml@ref) run with the same trust as actions and are pinned the same way. Not reported, by campaign policy: temporalio/* refs (first-party, pinned by internal process), local ./ actions, self-repository $/ refs (resolve to the running commit, so they are already pin-equivalent), and docker:// images (pinned by digest as a separate ecosystem).

---

Suppress findings

Add a noopengrep comment on the line before the finding:

# noopengrep: <rule-id>

[tekkaya]

@tekkaya Checking in on this! Is this ready for review?

Now it is ready for review