~maas-committers/maas/+git/temporal:chetan_fix_tests

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

f57bafe... by Chetan Gowda <email address hidden> on 2024-03-22

Tests - Fix how matching service client is accessed in functional tests

b0bb9b8... by Prathyush PV <email address hidden> on 2024-03-22

Adding history.TaskDLQUnexpectedErrorAttempts in dlq doc (#5581)

## What changed?
Adding history.TaskDLQUnexpectedErrorAttempts to DLQ documentation.

## Why?
This feature will be released in 1.23.

## How did you test it?

## Potential risks
None

## Documentation

## Is hotfix candidate?
No

4235063... by Quinn on 2024-03-22

Update Go SDK to official release (#5576)

Update Go SDK to official release v1.26.0

fb005be... by Michael Snowden <email address hidden> on 2024-03-21

Refactor nexus.OutgoingServiceRegistry (#5566)

## What changed?
<!-- Describe what has changed in this PR -->
I reviewed the Nexus outgoing service registry code and found a few
issues that this PR cleans up. None of them are functional, just
performance / code structure.

## Why?
<!-- Tell your future self why have you made these changes -->

## 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) -->

dbb2b94... by David Reiss <email address hidden> on 2024-03-21

Don't use tag for unknown namespace name in authorizer (#5472)

## What changed?
Don't use an unknown namespace name for a metric tag in authorizer.

## Why?
We should only use user-defined data in tags after validation.

## How did you test it?
new unit test

## Potential risks
just metrics

24639dc... by "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> on 2024-03-21

Bump google.golang.org/protobuf from 1.32.0 to 1.33.0 in /build (#5530)

Bumps google.golang.org/protobuf from 1.32.0 to 1.33.0.

[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=google.golang.org/protobuf&package-manager=go_modules&previous-version=1.32.0&new-version=1.33.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/temporalio/temporal/network/alerts).

</details>

Signed-off-by: dependabot[bot] <email address hidden>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Yimin Chen <email address hidden>

98a556b... by Prathyush PV <email address hidden> on 2024-03-21

Config to specify error substrings to DLQ task processing errors (#5536)

## What changed?
Adding a new config history.DLQErrorSubStrings to specify substrings in
task processing error strings.
If the error contains this substring, this task will be enqueued to DLQ.

## Why?
Gives the ability to send tasks to DLQ based on errors.

## How did you test it?
Unit tests

## Potential risks
None

## Documentation
None

## Is hotfix candidate?
No

---------

Co-authored-by: Tim Deeb-Swihart <email address hidden>

e8814c5... by Rodrigo Zhou <email address hidden> on 2024-03-20

Dynamic config to suppress error when setting system search attributes (#5561)

## What changed?
<!-- Describe what has changed in this PR -->
Dynamic config to suppress error when setting system search attributes

## Why?
<!-- Tell your future self why have you made these changes -->
Create a way to prevent errors when new system search attributes are
added, but there is already a custom search attribute registered with
the same name.

## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added 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) -->

a98b60e... by Michael Snowden <email address hidden> on 2024-03-20

Don't compare an issueSet with nil (#5563)

## What changed?
<!-- Describe what has changed in this PR -->
There was a small issue in #5523 where we check an "issue set" against
nil in the outgoing service registry code. The issue set is supposed to
track a list of request issues to form one big invalid argument error if
its length is greater than zero. However, we had code that looked like
this:

```go
if issues := getIssuesFromCommonRequest(req); issues != nil {
  return nil, issues.GetError()
}
```

Which works because we return a nil issues set if there's no issues,
but, technically, we could have a non-nil issues set with no issues, so
it should instead be something like this:

```go
if err := getIssuesFromCommonRequest(req).GetError(); err != nil {
  return nil, err
}
```

## Why?
<!-- Tell your future self why have you made these changes -->

## 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) -->

970e80f... by Michael Snowden <email address hidden> on 2024-03-20

Implement Nexus outgoing service registry (#5523)

## What changed?
<!-- Describe what has changed in this PR -->
I implemented the operator service CRUD APIs for Nexus outgoing
services.

## Why?
<!-- Tell your future self why have you made these changes -->

## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
There's nearly 100% test coverage across unit tests and functional
tests. It's only not 100% because of redundancy between create / update.

## 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) -->

---------

Co-authored-by: Roey Berman <email address hidden>