# Looking up an existing workflow and associated testing support **URL:** \ **Category:** Community Support\ **Tags:** java-sdk\ **Created:** [October 30, 2024, 7:36pm UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929 "2024-10-30T19:36:26Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![rocketraman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/rocketraman/32/3687_2.png) [@rocketraman](https://community.temporal.io/u/rocketraman)\ **Post date:** [October 30, 2024, 7:36pm UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/1 "2024-10-30T19:36:26Z")
I have a use case which requires looking up an existing workflow via search attribute – basically an existing workflow is signaled when an inbound REST API call is made, based on some external event. Ideally this call would simply contain the workflow ID but its an external call and I have no control over its content. I have therefore implemented a workflow lookup via `listExecutions` and a query for various search attributes which I can obtain from the event. This works fine in production, but in my integration test code which uses the Temporal internal test server, I am unable to call this API (see [this forum post](https://community.temporal.io/t/inability-to-list-workflow-executions-with-test-environment/7471) and [this SDK issue](https://github.com/temporalio/sdk-java/issues/1693)). My current test code has a terrible hack in it which injects the workflow lookup code, and in prod it does the usual listWorkflows, but in test it sets and uses the workflow id. This works but is messy and I’d like to avoid it. A contributor comment on [this issue](https://github.com/temporalio/sdk-java/issues/1139) says this: > Assigning low priority. > Test Server is intended for testing Workflow implementations, full on-par support of all administrative endpoints is not really a goal. Workflow logic shouldn’t trigger listopenworkflowexecutions, it’s an admin/operation endpoint. If listing workflows is not intended to be used except for administrative purposes, how would I implement the use case I have described? Isn’t this a common scenario? ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [October 31, 2024, 6:16pm UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/2 "2024-10-31T18:16:36Z")
Note that listExecutions API has pretty tight rate limits as ES doesn’t scale in terms of the number of queries. If this scenario needs to scale, you have to use an external DB to perform the WorkflowID lookup. ---
**Author:** ![rocketraman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/rocketraman/32/3687_2.png) [@rocketraman](https://community.temporal.io/u/rocketraman)\ **Post date:** [November 11, 2024, 10:52pm UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/3 "2024-11-11T22:52:17Z")
Follow-up question… I don’t need this to scale so I was fine with searching for a workflow via search attributes. However, I am finding that I have a race condition: after my in-workflow call to `upsertTypedSearchAttributes` (Java SDK), the workflow is not immediately searchable by the upserted value. Pulling in an external database dependency is of course possible but it feels like overkill for this use case. I would have thought that finding existing workflows is such a common Temporal use case that this kind of logic would be supported out of the box without having to deal with this kind of race. ---
**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\ **Post date:** [November 12, 2024, 12:21am UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/4 "2024-11-12T00:21:31Z")
Unfortunately, it is impossible to provide read-after-write consistency as Elastic Search doesn’t support it. ---
**Author:** ![rocketraman](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/rocketraman/32/3687_2.png) [@rocketraman](https://community.temporal.io/u/rocketraman)\ **Post date:** [November 13, 2024, 3:14pm UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/5 "2024-11-13T15:14:43Z")
> Unfortunately, it is impossible to provide read-after-write consistency as Elastic Search doesn’t support it. Not quite true: the [refresh parameter](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-refresh.html) does support the `true` or `wait_for` values which do provide read-after-write consistency. Specifying `true` would probably not be a good idea for load reasons, but it seems like a search attribute update could benefit from `wait_for` , which for active indices should only wait up to a second or so if ES is using its [default configuration](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html#refresh-api-desc). It might make sense to make the async nature of the current API explicit in the docs, and provide a new `upsertTypedSearchAttributesSync` API that specifies `refresh=wait_for` on the ES index call. ---
**Author:** ![rodrigozhou](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/rodrigozhou/32/3393_2.png) [@rodrigozhou](https://community.temporal.io/u/rodrigozhou)\ **Post date:** [November 14, 2024, 12:24am UTC](https://community.temporal.io/t/looking-up-an-existing-workflow-and-associated-testing-support/14929/6 "2024-11-14T00:24:17Z")
Hi @rocketraman, thanks for letting us know of this option. We will evaluate this, and see if we can support this option.