…#602)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
Adding a `cause` field to `RespondQueryTaskCompletedRequest` similar to
`RespondWorkflowTaskFailedRequest`.

<!-- Tell your future self why have you made these changes -->
**Why?**
Server needs a clean way to distinguish NDE and some other
versioning-related errors for the dry-run API and user-experience
insights.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
No

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
None at the moment.- SDK needs to send the info

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
adding a timestamp to `TriggerImmediatelyRequest` message

<!-- Tell your future self why have you made these changes -->
We can make the wft “more idempotent”: put the desired trigger time in
the trigger immediately request itself, so it goes in the signal
payload, so all wfts attempt to start the target with the same id.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
[**Server PR**](temporalio/temporal#7968)

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**

(1) Deprecated `task_queue_infos` in
`deployment.WorkerDeploymentVersionInfo`.
(2) Added `version_task_queues` to
`DescribeWorkerDeploymentVersionResponse`.

<!-- Tell your future self why have you made these changes -->
**Why?**

We want to report task queue stats for each task queue that is part of a
worker deployment version.

The challenge is that the `taskqueue` package depends on the
`deployment` package. So adding `TaskQueueStats` to
`deployment.WorkerDeploymentVersionInfo` causes a cycle import error.

Weighing our options, we decided to effectively _move_ the task
queue-related data from within the deployment package into the response
message.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**

Not yet; but in subsequent releases the deprecated field
`task_queue_infos` will be removed.

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**

temporalio/temporal#7959 (draft)

---------

Co-authored-by: Spencer Judge <sjudge@hey.com>

<!-- Describe what has changed in this PR -->
**What changed?**

Add "process_key" to the worker host info.
Make "worker_heartbeat" repeatable in "PollNexus" and "RecordHeartbeat"
APIs.

<!-- Tell your future self why have you made these changes -->
**Why?**

We decide to have a single Q per process. Thus we need a way to agree on
task queue name, and for that we need this information to be:
* available as a part of heartbeat
* unique across at least namespace
Process ID is not unique.

Since we send all heartbeats at once - we make them repeated.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
Not yet.

<!-- Describe what has changed in this PR -->
**What changed?**
remove exception for "workflowservice/v1/request_response.proto"

<!-- Tell your future self why have you made these changes -->
**Why?**

This file is important, I don't want to hide it from this check for a
long time.

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**
+ Boolean field added to DescribeTaskQueue request to control sending
task queue config in the response.
+ New messages for RateLimit and TaskQueueConfig
+ UpdateTaskQueueConfig api implementation: Created a
UpdateTaskQueueConfigRequest and UpdateTaskQueueConfigResponse.

<!-- Tell your future self why have you made these changes -->
**Why?**
+ Server needs an API endpoint for update TaskQueue RateLimits.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
+ No.

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**
+ PR for persistence of TaskQueueConfigs :
temporalio/temporal#8004

…(#614)

**Why?**

For debugging purposes.

<!-- Describe what has changed in this PR -->
Description: Add an operation for batch reset and update-options of
activities

<!-- Tell your future self why have you made these changes -->
Why: To support batching these changes

<!-- Are there any breaking changes on binary or code level? -->
No breaking changes

[Server PR](https://github.com/temporalio/temporal/pull/8061/files)

<!-- Describe what has changed in this PR -->
**What changed?**
Add new API for worker commands, and first few commands - Get/Set
Config.
Also add rudimentary config.

<!-- Tell your future self why have you made these changes -->
Part of worker commands work.
We should be able to send commands to the workers/receive response.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**
Yep.

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
[Server PR.](temporalio/temporal#8055)

**What changed?**

Already [discussed and approved previously
here](temporalio/api#513).

**Breaking changes**

N/A

**Server PR**

https://github.com/temporalio/temporal/tree/feature/fairness

---------

Co-authored-by: David Reiss <david@temporal.io>

_**READ BEFORE MERGING:** All PRs require approval by both Server AND
SDK teams before merging! This is why the number of required approvals
is "2" and not "1"--two reviewers from the same team is NOT sufficient.
If your PR is not approved by someone in BOTH teams, it may be summarily
reverted._

<!-- Describe what has changed in this PR -->
**What changed?**

Adding a breakdown of stats per-priority levels to the two APIs that
return task queue stats already.

<!-- Tell your future self why have you made these changes -->
**Why?**

To give users insights on a per priority level.

<!-- Are there any breaking changes on binary or code level? -->
**Breaking changes**

N/A

<!-- If this breaks the Server, please provide the Server PR to merge
right after this PR was merged. -->
**Server PR**

temporalio/temporal#8030