Modify elasticsearch to use term query for keyword matching (#5950)
## What changed?
<!-- Describe what has changed in this PR -->
- ElasticSearch query converter now uses term query if the search
attribute is of type KEYWORD or KEYWORD_LIST
- otherwise, it uses match query to support type TEXT matching in custom
search attribute
- added `searchattribute.NameTypeMap` in `comparisonExprConverter` to
support this
## Why?
<!-- Tell your future self why have you made these changes -->
- Improvement in performance: term query is generally faster than match
query
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- modified converter and elasticsearch unit tests accordingly to use
term query
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
Move frontend redirection interceptor to `interceptor` package (#5942)
## What changed?
<!-- Describe what has changed in this PR -->
Moved and renamed the frontend gRPC redirection interceptor to the
`interceptor` package.
## Why?
<!-- Tell your future self why have you made these changes -->
Required so that logic can be shared with Nexus components without
causing an import cycle.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Existing tests
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Fix flaky `TestWaitLifecycleStage` test by increasing timeout which
shouldn't fire 5 times. With former 2x buffer on slow runners user
timeout expires before `WaitLifecycleStage` is called.
## Why?
<!-- Tell your future self why have you made these changes -->
Test flakiness is bad.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Run it.
Move replicaton task filter to stream sender (#5728)
## What changed?
Move replicaton task filter to stream sender
## Why?
Task convertor should just do conversion.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Unit test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Implement tiered replication sender
## Why?
<!-- Tell your future self why have you made these changes -->
To allow sender to send task based on priority
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
unit test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
n/a
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
n/a
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
no
e55476d...
by
Tim Deeb-Swihart <email address hidden>
Dump only the type of request when we fail to find Namespace info (#5941)
## What changed?
We now only log the type of the request we failed to find namespace
details on rather than the contents of the request, which required
expensive reflection.
## Why?
This is an expensive error path otherwise. We discovered we spent more
time in this error path than in our actual logic when running an
experiment
Workflow Update: improve "update not found" error message (#5935)
## What changed?
<!-- Describe what has changed in this PR -->
Improve "update not found" error message.
Also change `nonRetryable` flag on failure to `false` (meaning that
failure is retryable). This failure is not used by the code, but just
goes to the history and shows up in UI. Because WFT failures are
retryable, setting it to `false` is more accurate.
## Why?
<!-- Tell your future self why have you made these changes -->
When update is not found while handling messages from worker, it is most
likely means that update registry was cleared but retries on the caller
side will recreate it. I am trying to phrase it in the way it clearly
says that it is not an user error.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
N/A
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
No.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
Yes, to 1.24.0.
7635cd7...
by
Stephan Behnke <email address hidden>
Add permission for staleness GitHub Action (#5936)
## What changed?
<!-- Describe what has changed in this PR -->
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
I can't?
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
