Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Typed search attributes inside schedule actions are not printed correctly in text mode #590

Open
josh-berry opened this issue Jun 7, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@josh-berry
Copy link
Collaborator

What are you really trying to do?

As the description says.

This may apply in other situations, too—any situation in which we wrap typed search attributes inside another object in the CLI code would be impacted. Also, this is worse with server 1.24 because that server now returns schedule search attributes as typed search attributes. So search attributes that would have been returned from 1.23 and earlier are now missing from CLI output.

This can be worked around by using JSON output instead (-o json), which prints the attributes correctly.

Describe the bug

Typed search attributes are printed correctly when they are printed as part of a proto.Message, but incorrectly when printed as part of a normal JSON object. This is likely because there is no Marshaler implementation for SearchAttributes in the Go SDK.

We don't necessarily want to add one, either, as this might be unnecessary for most people, so we should try to come up with a workaround for this in the CLI instead.

Minimal Reproduction

Launch a 1.24.1 server (a CLI which uses 1.24.1 can be built from #584):

./temporal server start-dev

Then create a search attribute and schedule which uses the search attribute:

❯ ./temporal operator search-attribute create --name CustomKeywordField --type Keyword
Search attributes have been added

❯ ./temporal schedule create -s foo --task-queue foo --type foo --workflow-id asdf --interval 10d --search-attribute CustomKeywordField=\"schedule-string-val\"

When describing the schedule in text mode, notice the Action's TypedSearchAttributes field is empty:

❯ ./temporal schedule describe -s foo
  ScheduleId        foo
  Action            {"ID":"asdf","Workflow":"foo","Args":[],"TaskQueue":"foo","WorkflowExecutionTimeout":0,"WorkflowRunTimeout":0,"WorkflowTaskTimeout":10000000000,"RetryPolicy":null,"Memo":{},"TypedSearchAttributes":{},"UntypedSearchAttributes":{}}
  Spec              [{"every":"10d 0h 0m 0s"}]
  Jitter            0s
  OverlapPolicy     Skip
  CatchupWindow     365d 0h 0m 0s
  PauseOnFailure    false
  Paused            false
  NextRunTime       1 week from now
  LastRunTime
  RunningWorkflows  []
  CreatedAt         1 minute ago
  LastUpdateAt      a long while ago
  ActionCounts      {"Total":0,"MissedCatchupWindow":0,"SkippedOverlap":0}

However, the schedule prints correctly in JSON mode:

❯ ./temporal schedule describe -s foo -o json
{
  "schedule": {
...
    "action": {
      "startWorkflow": {
        "workflowId": "asdf",
        "workflowType": {
          "name": "foo"
        },
        "taskQueue": {
          "name": "foo",
          "kind": "TASK_QUEUE_KIND_NORMAL"
        },
        "input": {},
        "workflowExecutionTimeout": "0s",
        "workflowRunTimeout": "0s",
        "workflowTaskTimeout": "10s",
        "searchAttributes": {
          "indexedFields": {
            "CustomKeywordField": {
              "metadata": {
                "encoding": "anNvbi9wbGFpbg==",
                "type": "S2V5d29yZA=="
              },
              "data": "InNjaGVkdWxlLXN0cmluZy12YWwi"
            }
          }
        },
        "header": {}
      }
    },
    "policies": {
      "overlapPolicy": "SCHEDULE_OVERLAP_POLICY_SKIP",
      "catchupWindow": "31536000s"
    },
    "state": {}
  },
...
}

Environment/Versions

  • OS and processor: any
  • Temporal Version: CLI 0.12 and Server 1.24
  • Are you using Docker or Kubernetes or building Temporal from source? source, as above

Additional context

@josh-berry josh-berry added the bug Something isn't working label Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant