feat: add tdbg CLI command to get user data for a task queue partition by veeral-patel · Pull Request #9935 · temporalio/temporal

veeral-patel · 2026-04-13T22:07:20Z

What changed?

This PR adds a tdbg taskqueue get-user-data CLI command to tdbg to get the TaskQueueUserData for a particular task queue partition.

This PR depends on #9934. See #9934 for more context.

Files changed

File	Change
`tools/tdbg/tdbg_commands.go`	Registered `get-user-data` subcommand under `taskqueue` with `--namespace`, `--task-queue`,`--task-queue-type`, and `--partition-id` flags
`tools/tdbg/task_queue_commands.go`	Implemented `AdminGetTaskQueueUserData`: reads flags, calls `AdminService.GetTaskQueueUserData`, pretty-prints response
`tools/tdbg/task_queue_commands_test.go`	Added unit tests

How did you test it?

built
run locally and tested manually
added new unit test(s)
added new integration test(s) — not applicable
added new functional test(s) — not applicable (CLI change)

Unit tests

Test case	Input	Expected
Missing namespace	`--task-queue my-queue` only	Error before RPC is called
Missing task queue	`--namespace default` only	Error before RPC is called
Invalid task queue type	`--task-queue-type INVALID`	`StringToEnum` returns error before RPC is called
Unspecified task queue type	`--task-queue-type TASK_QUEUE_TYPE_UNSPECIFIED`	Defaults to `TASK_QUEUE_TYPE_WORKFLOW`, succeeds
Root partition (default)	Valid flags, no `--partition-id`	Calls RPC with `partition_id=0`, prints response
Non-root partition	`--partition-id 1`	Calls RPC with `partition_id=1`, prints response

Manual tests

Setup

make start-sqlite
temporal operator namespace create -n default
temporal task-queue versioning insert-assignment-rule --namespace default --task-queue my-queue --build-id "test-build-1" --rule-index 0 --yes
temporal task-queue config set --namespace default --task-queue my-queue --task-queue-type activity --queue-rps-limit 50 --queue-rps-limit-reason "manual test"

Root partition, workflow type

$ ./tdbg taskqueue get-user-data --namespace default --task-queue my-queue --task-queue-type TASK_QUEUE_TYPE_WORKFLOW
{
  "version": "2"
}

version=2 reflects writes from the assignment rule; user_data absent as expected (versioning rules live in versioning_data, not
per_type).

Root partition, activity type

$ ./tdbg taskqueue get-user-data --namespace default --task-queue my-queue --task-queue-type TASK_QUEUE_TYPE_ACTIVITY
{                                                                                                                                             
  "version": "2",
  "user_data": {                                                                                                                              
    "config": {                                           
      "queueRateLimit": {
        "rateLimit": { "requestsPerSecond": 50 },                                                                                             
        "metadata": { "reason": "manual test", "updateTime": "..." }
      }                                                                                                                                       
    }                                                     
  }
}

user_data populated with the rate limit config set via UpdateTaskQueueConfig.

Non-root partition, workflow type

$ ./tdbg taskqueue get-user-data --namespace default --task-queue my-queue --task-queue-type TASK_QUEUE_TYPE_WORKFLOW --partition-id 1
{                                                                                                                                             
  "version": "2"
}

Same version as root — replication is working.

Non-root partition, activity type

$ ./tdbg taskqueue get-user-data --namespace default --task-queue my-queue --task-queue-type TASK_QUEUE_TYPE_ACTIVITY --partition-id 1
{
  "userData": {
    "config": {
      "queueRateLimit": {
        "rateLimit": {
          "requestsPerSecond": 50
        },
        "metadata": {
          "reason": "manual test",
          "updateTime": "2026-04-13T21:40:39.888Z"
        }
      }
    }
  },
  "version": "2"
}

Unspecified type defaults to workflow

$ ./tdbg taskqueue get-user-data --namespace default --task-queue my-queue --task-queue-type TASK_QUEUE_TYPE_UNSPECIFIED
{
  "version": "2"
}

Passing TASK_QUEUE_TYPE_UNSPECIFIED defaults to workflow type instead of erroring — output matches the workflow-type test above.

CLAassistant · 2026-04-13T22:07:28Z

All committers have signed the CLA.

dnr

As an aside, the PR description is really verbose and has a lot of unnecessary detail. That goes into the commit message, so it'll show up in git log, etc. I'd suggest trimming that down to just the important stuff.

dnr · 2026-04-13T22:41:05Z

+  string namespace = 1;
+  string task_queue = 2;
+  temporal.api.enums.v1.TaskQueueType task_queue_type = 3;
+  // If non-zero, fetch the user data loaded by this partition instead of the root.


You don't have to say this, zero is the root so it's always the partition id you're asking about

This change was removed from this PR. RPC changes were merged in #9934

dnr · 2026-04-13T22:42:10Z

+  string task_queue = 2;
+  temporal.api.enums.v1.TaskQueueType task_queue_type = 3;
+  // If non-zero, fetch the user data loaded by this partition instead of the root.
+  int32 partition_id = 4;


But is there some reason we need the type and partition id? User data is defined on the task queue family (i.e. identified by namespace + task queue name, across types), so they should all be the same. Is it just for debugging?

This change was removed from this PR. RPC changes were merged in #9934

dnr · 2026-04-13T22:42:44Z

+	}
+	tqType := enumspb.TaskQueueType(tlTypeInt)
+	if tqType == enumspb.TASK_QUEUE_TYPE_UNSPECIFIED {
+		return errors.New("invalid task queue type") // nolint


if we do keep this field/flag, we should just default to workflow instead of erroring

I was considering that too! But based on the Jira ticket, queue name and type should be mandatory, and partition-id should be optional. So I think this should be good!

We need a tdbg task-queue get-user-data that returns the User Data stored in server for a particular task queue name + type

Also it should have an optional --partition-id arg so user can ask to fetch the data loaded from a given partition rather than getting it from the root partition (default behavior)

Not sure I interpret that as having the type to always be specified; I think @dnr is right here in that if a user does not specify a task queue type, we should default this to being the workflow type

@Shivs11 fixed!

Adds AdminService.GetTaskQueueUserData proto + generated code, and wires it up as a tdbg command. Accepts --task-queue (required), --task-queue-type (default: workflow), and --partition-id (default: 0). The backend handler implementation is in a separate PR. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…mand Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Shivs11

couple of small comments

Shivs11 · 2026-04-15T18:31:57Z

 			},
 		},
+		{
+			Name:  "get-user-data",


I think we should name this as "get-task-queue-user-data"; Looking at the way the other commands have also been formulated, it seems like we should be explicit with our naming here!

@Shivs11 fixed!

- Rename command from get-user-data to get-task-queue-user-data for consistency with other tdbg taskqueue subcommands - Default to TASK_QUEUE_TYPE_WORKFLOW when UNSPECIFIED is passed instead of returning an error Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Shivs11

approving in confidence that you address this comment too!

Shivs11 · 2026-04-15T19:38:00Z

 					Name:  FlagTaskQueueType,
 					Value: "TASK_QUEUE_TYPE_WORKFLOW",
 					Usage: "Task Queue type: TASK_QUEUE_TYPE_WORKFLOW, TASK_QUEUE_TYPE_ACTIVITY, TASK_QUEUE_TYPE_NEXUS",
 				},


Quite similar to the partitionID usage message, we should now include that the default task queue type is indeed workflow type so that a user knows that they do not need to input this value

ShahabT · 2026-04-15T19:57:36Z

+
+// TestGetTaskQueueUserData tests that the cli accepts the various arguments for get-task-queue-user-data.
+func (s *taskQueueCommandTestSuite) TestGetTaskQueueUserData() {
+	baseCommand := []string{"tdbg", "taskqueue", "get-task-queue-user-data",


task-queue seems redundant, tdbg taskqueue get-user-data reads better

oh good point, I forgot the command starts with a task-queue.

- Revert command name from get-task-queue-user-data back to get-user-data - Add "(default TASK_QUEUE_TYPE_WORKFLOW)" to --task-queue-type usage string Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

veeral-patel requested review from a team as code owners April 13, 2026 22:07

dnr reviewed Apr 13, 2026

View reviewed changes

veeral-patel requested a review from Shivs11 April 13, 2026 23:10

Veeral Patel and others added 3 commits April 14, 2026 18:36

fix: add missing --namespace flag to tdbg taskqueue get-user-data com…

cb3b0de

…mand Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix tests

7a8e6b1

veeral-patel force-pushed the feature/task-queue-get-user-data-cli branch from daf36a3 to 7a8e6b1 Compare April 15, 2026 01:37

fix: remove duplicate GetTaskQueueUserData method in admin client

81681b4

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Shivs11 reviewed Apr 15, 2026

View reviewed changes

Shivs11 approved these changes Apr 15, 2026

View reviewed changes

ShahabT reviewed Apr 15, 2026

View reviewed changes

veeral-patel merged commit 5bd15b0 into temporalio:main Apr 15, 2026
46 checks passed

Conversation

veeral-patel commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

Files changed

How did you test it?

Unit tests

Manual tests

Uh oh!

CLAassistant commented Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dnr left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

veeral-patel Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Shivs11 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Shivs11 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

veeral-patel commented Apr 13, 2026 •

edited

Loading

CLAassistant commented Apr 13, 2026 •

edited

Loading

veeral-patel Apr 15, 2026 •

edited

Loading