Adding MessageCount to ListQueues response (#5130)
<!-- Describe what has changed in this PR -->
**What changed?**
Adding a new field MessageCount to ListQueues response.
<!-- Tell your future self why have you made these changes -->
**Why?**
This field will be useful for operators who wants to get details about
DLQs
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Unit tests with 100% test coverage.
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
Add test to verify that NamespaceValidator will reject request if namespace name from task does not match name from request (#5121)
<!-- Describe what has changed in this PR -->
**What changed?**
one test case added
<!-- Tell your future self why have you made these changes -->
**Why?**
cover requirement
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
run test, made sure that when assertion is incorrect the test will fail
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
no impact
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No
Record child start event if missing during record child complete (#5067)
<!-- Describe what has changed in this PR -->
**What changed?**
Added new logic to record child workflow started event if it is missing
when record child workflow complete is called.
Add Import function to executableTask implementation (#5099)
<!-- Describe what has changed in this PR -->
**What changed?**
Add Import function to executableTask implementation
<!-- Tell your future self why have you made these changes -->
**Why?**
As a building block for handling import task
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
unit test
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
no risk. Not wired into current logic.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No.
<!-- Describe what has changed in this PR -->
**What changed?**
Parse `STARTS_WITH` queries to visibility, and build queries to
Elasticsearch and SQL.
<!-- Tell your future self why have you made these changes -->
**Why?**
Support prefix search in visibility queries.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Added unit tests, and integration tests.
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
No.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No.
### Empty responses on server-timeout
The behavior of `PollWorkflowExecutionUpdate` and
`UpdateWorkflowExecution` was changed as follows:
- They introduce a "server-imposed deadline" equal to current time plus
`LongPollExpirationInterval`
- If a timeout occurs due to the server-imposed deadline, then they do
not return an error, but return a response with an empty outcome.
- Otherwise, their behavior is unchanged (in particular, if a timeout
occurs due context deadline expiry, they return the error as before)
### Non-blocking poll
- Change the Update Poll endpoint so that omitting the `WaitPolicy` now
means "do not wait; respond with current Update status without
blocking". Previously omitting the `WaitPolicy` was interpreted to mean
"attempt to wait until Completed"
- Also return the `UpdateRef`
## Why?
### Empty responses on server-timeout
- This makes the behavior of the endoint consistent with
`GetWorkflowExecutionHistory`.
- This makes sense, because that endpoint is used in an analogous way
(e.g. `GetWorkflowExecutionHistory` is used for `wfHandle.result()` and
`PollWorkflowExecutionUpdateRequest` is used for
`updateHandle.result()`, and both involve polling for the result).
- In particular, a polling client interprets
timeout-on-server-imposed-deadline to mean that it should continue
polling, and we would prefer not to use an error to communicate this
non-exceptional situation.
### Non-blocking poll
SDK clients may use non-blocking poll to, for example
- Obtain current status of an Update (perhaps `updateHandle.describe()`
- Determine whether an Update with a given ID already exists / is
running
### How did you test it?
- Unit tests
- Modified Typescript SDK to not send `WaitPolicy`, ran a feature test
against the modified server and modified SDK, and confirmed API
communication as expected (this revealed that I needed to stop Frontend
mutating the request to set `WaitPolicy` to `Completed`).
- I changed the poll loop in sdk-typescript to no longer catch
`DeadlineExceeded`, ran the `update/basic_async` feature test against
the local SDK and against server binaries built prior to and with this
commit, and confirmed that the change in this PR fixed the poll loop.
### Potential risks
- Could break Update operations in SDKs
