GetTaskQueueUserData returns success on task queue closing (#5430)
## What changed?
GetTaskQueueUserData returns a successful "no change" when the task
queue is closing, instead of an Unavailable error.
## Why?
1. The caller will retry on both success and failure, so it doesn't
really matter.
2. Returning success avoids misleading logs about errors (this was
improved in #5227 but still happens on service deployment/restart).
3. More subtly, an unavailable error is actually retried by the server
interceptor, which causes the task queue to be reloaded again. This can
cause extra bouncing of task queues during deployment and increase
latency. A success is not retried.
## How did you test it?
changed unit test, tested locally with matching restarts
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
768fa6e...
by
Tim Deeb-Swihart <email address hidden>
history: ensure that activity run timeouts are non-nil (#5445)
## What changed?
Run timeouts for schedule activity events events will always be valid.
## Why?
In 1.22 we always had a valid run timeout when checking schedule
activity events; even though it was a `*time.Duration` in the proto
message we converted it to a full `time.Duration` value before
validating the command. With the proto rework in 1.23 that was dropped
and we pass the `*durationpb.Duration` through without checking it's
validity.
This causes the TypeScript SDK to crash as it assumes that the
ScheduleToStart and ScheduleToClose timeouts are always valid.
Since we can't force all our users to upgrade their SDKs for obvious
reasons, we're going to ensure we behave just like we did in 1.22
Ensure PollActivityTaskQueueResponse.ScheduleToCloseTimeout is not nil (#5444)
## What changed?
In description.
## Why?
This field should never be nil as expected by the TS SDK.
This may happen if ScheduleActivityExecution was recorded in version
1.23 and the server was rolled back.
3532e35...
by
Carly de Frondeville <email address hidden>
docs: add PR template reminder, Makefile, and assets folder (#5423)
## What changed?
- Add PR template reminder to update docs
- Add first d2 diagram to Matching README (more to follow)
- Refactor `docs` folder to contain an `assets` folder where we store
images for all the READMEs in the project, instead of using github
assets
## Why?
To improve how we interact with and update docs
## How did you test it?
n/a
## Potential risks
n/a
## Is hotfix candidate?
no
---------
Co-authored-by: Stephan Behnke <email address hidden>
Co-authored-by: Dan Davison <email address hidden>
Remove history queue reader registration logic (#5420)
## What changed?
<!-- Describe what has changed in this PR -->
- Remove unused persistence API for registering queue readers and
updating it's progress.
## Why?
<!-- Tell your future self why have you made these changes -->
- Those APIs are adding for a deprecated design
## 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? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
Deprecate taskCategoryRegistry usage for DLQ Key on frontend (#5442)
## What changed?
<!-- Describe what has changed in this PR -->
- Deprecate taskCategoryRegistry usage for DLQ Key on frontend
## Why?
<!-- Tell your future self why have you made these changes -->
- Frontend should not use task category registry. That component should
be used only by history service.
## 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? -->
## 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.
