Started using temporal server start-dev for local development and was able to successfully add search attributes. The search attributes show up when I run temporal operator search-attribute list but when the workflow attempts to call Workflow.upsertSearchAttributes it gets an error:
io.grpc.StatusRuntimeException: INVALID_ARGUMENT: BadSearchAttributes: Namespace my-namespace has no mapping defined for search attribute Type
(my-namespace is the name of the namespace and the name of the attribute is called “Type”).
I also noticed that in the Temporal UI when I look at the Search Attributes list in the namespace, instead of the names I gave them, they just show up as “Keyword01”, “Keyword02”, etc.
I can’t seem to reproduce this issue with Temporal CLI 0.9.0.
To eliminate a possibility, can you confirm you are adding the search attribute to the correct namespace my-namespace and you can see it from temporal operator search-attribute list --namespace my-namespace?
Earlier, I relied on exporting the environment variable TEMPORAL_NAMESPACE to set the namespace.
As a test, I removed the attribute using tctl, then re-added it using temporal specifying the namespace option explicitly and it now works. Perhaps there’s an issue with the env variable not getting picked up, I haven’t tested that.
The output from search-attribute list looks the same as previously, so it’s not possible to see any difference there.
The Temporal UI never the less doesn’t seem to display the search attributes for the namespace correctly like the CLI does.
I am on the same version of temporal as you
temporal version 0.9.0 (server 1.20.2) (ui 2.15.0)
Can confirm - UI and temporal CLI (as well as API using golang SDK) show different list of attributes. Custom attributes seem to be created successfully over CLI or API, but adding them to workflow results in Namespace default has no mapping defined for search attribute <attribute name>
Temporal CLI 0.9.0, SQLLite persistance.
Attempting to set/unset system.forceSearchAttributesCacheRefreshOnRead has no affect
Hello there! I face the same issue with typescript SDK (upsertSearchAttributes) & typescript worker, while creating the attributes correctly and seeing them in the temporal web UI and using cli (temporal operator search-attribute list).
"message": "BadSearchAttributes: Namespace MY_NAMESPACE has no mapping defined for search attribute MY_SEARCH_ATTRIBUTE",
@karney Thanks for pointing out the misleading env var names in CLI’s prompt. I’ll follow up it from my side. This has been fixed here and should be included in the next release with updated document too.
Firstly, I’d like to acknowledge the defect in the UI where the custom search attributes are not showing up accordingly:
Now, based on what Karney described above, as well as my earlier test, the error message such as Namespace default has no mapping defined for search attribute <attribute name> may have something to do with different namespaces being used while creating the custom attribute and consuming/updating it. Note, custom attributes are scoped to namespaces. So it’d be great if you could help me to double check this scenario first. Thanks!
I tend to think that issue is related to back-end, not to UI. Mostly, because we cant create workflow with just created search attributes (as well as upsert them to the workflow).
As far namespace part - the UI says i’ve got only “default”. I see “default” and “temporal-system” in DB and all custom attributes are created with passing “default” explicitly.
Is there anything else i can check in SQLLite to help you with figuring out?
I was able to register the values in the non-default namespace after specifying it explicitly using the namespace option in the command. The initial problem is likely because of the env var not having any effect.
so it works perfectly well. now it gets a bit interesting. I tried to do the same with my code (adding an attribute via temporal client and then starting the workflow) and it doesn’t work. Probably, something is related to caching or asynchronous nature of adding new search attribute. The temporal is run as: temporal server start-dev -n default -db-filename db --dynamic-config-value system.forceSearchAttributesCacheRefreshOnRead=true
Well, it looks like there are two separate issues - with UI showing incorrect list of attributes and on my end with caches.
So, my sequence of actions:
Start the dev server, wait for cluster to become healthy
Add new search attributes over client SDK
Execute list attributes, make sure new attributes are returned
Start new workflow that uses just created attributes (also over client SDK)
As result, search attributes aren’t available for the workflow and the result is Namespace default has no mapping defined for search attribute)
Still, if i add some 20 secs wait in between of (3) and (4) - it works perfectly fine. The same reproduces regardless the value system.forceSearchAttributesCacheRefreshOnRead set to
@tao Is there any way to make sure that custom search attributes are available for use by ExecuteWorkflow? There is still some time in between of ListSearchAttributes returns new attributes and ExecuteWorkflow stops responding with the error that attribute isn’t defined
Am I right in saying that there’s still an issue with displaying the custom search attributes in the UI? This is what I’ve still noticed when starting a temporal dev server using the latest Temporal CLI. The actual search attribute is registered and creating workflows that set that search attribute succeeds, so it sounds like a bug on the UI side.