## What changed?
A critical bug was fixed in PR #6538. These are the associated tests to
prevent regression.
## Why?
Adding tests for a bug fix.
## How did you test it?
Reverted the PR locally and ensured the tests catch it.
## Potential risks
N/A
## What changed?
Make import formatting a part of the build, and test validity with
"ensure-no-changes" target
## Why?
So we never discuss import order again (hopefully)
## How did you test it?
its a build change, so the build will test it!
## Potential risks
As long as build works, the only thing I risk is the ire of coworker who
want imports to be different ;)
## Documentation
N/A
## Is hotfix candidate?
No
## What changed?
Add "start_time" nullable column to the current_executions table.
Some refactoring of the existing code - send row as a parameter rather
then every single field of that row.
## Why?
Adding column - to allow fast checking workflow creation time to avoid
noisy workflow restarts. Without it we need to get workflow start time
from a mutable state, which can affect latency.
## Is hotfix candidate?
No
## What changed?
SQL config now supports passing a connect function.
## Why?
It's currently not possible to embed a Temporal server to a host
application where the database connection is managed by the host
application and is provided as a database connector. This allows the
host application to pass a db connector rather than the the individual
sql config strings.
## How did you test it?
I have embedded this code into a custom application and verified that
the connector is working properly.
## Potential risks
This is a non-breaking change with very minimal risks.
## Is hotfix candidate?
No.
## What changed?
Both our PostgreSQL and MySQL database backends will now automatically
reconnect to the database when certain errors occur: all errors chosen
have been experienced when testing this behavior through an AWS Aurora
RDS failover of either MySQL or PostgreSQL.
For both backends we will reconnect when we see:
- `ECONNRESET`
- `ECONNABORTED`
- `ECONNREFUSED`
- `io.EOF`
- `io.ErrUnexpectedEOF`
- `database/sql/driver.ErrBadConn`
for postgres we will also reconnect on the following SQLStates:
- `25006` read-only transaction
- `57P03` cannot connect now
- `0A000` feature not supported, but ONLY when the message is `cannot
set transaction read-write mode during recovery`
for mysql we will also reconnect when we see the following error codes:
- `1040` too many connections
- `1792` read-only transaction (SQLstate `25006`)
- `1836` running in read-only mode
This logic is easily extensible should we discover more failure modes
over time
## Why?
We've had multiple community reports of Temporal problems during RDS
failover. One part of this is the fact that we wouldn't necessarily
reconnect; we were at the whims of our chosen SQL abstraction's
connection pooling logic.
## How did you test it?
I manually tested this functionality in the presence of repeated RDS
failovers:
- [x] postgres12 plugin with pq driver
- [x] postgres12 plugin with pgx driver
- [x] mysql plugin
Automated testing will be added to our regular testing pipelines once
our infrastructure friends have added the support I need (it's in
progress)
## Potential risks
We're concerned there's a correctness issue in our PostgreSQL backend
that's related to our behavior during an RDS failover. If we merge this
before I figure out what's going on, we could hide the issue and make it
harder to reproduce.
## Documentation
N/A
## Is hotfix candidate?
Yes?
## What changed?
- Refactored Nexus Registry code to merge incoming and outgoing into one
registry
- Added separate concept of "endpoints" - which is roughly analogous to
what was previously called "services"
- Upgraded the Nexus Go SDK and API dependencies accordingly
- Command handler interface was modified to accept a context given new
requirements
- Note that invoking a worker endpoint is not yet supported, there will
be some minor restructuring required to enable that
- Requires this unmerged API PR
https://github.com/temporalio/api/pull/403. The two PRs should be merged
together.
## Why?
Part of late redesign. See also https://github.com/nexus-rpc/api/pull/5
## How did you test it?
Modified existing and added new tests.
## What changed?
Noticed that `db.CreateTask` and `persistence.CreateTask` were
relatively unused and could be removed.
## How did you test it?
Current CI/CD tests
## Potential risks
Could break things if an unseen component were to use these methods;
have checked it to the best of my abilities.
## Is hotfix candidate?
No
## What changed?
<!-- Describe what has changed in this PR -->
Added a new persistence layer API to get a Nexus incoming service by
service ID.
## Why?
<!-- Tell your future self why have you made these changes -->
To align with new API requirements
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Updated existing tests
---------
Co-authored-by: Roey Berman <[email protected]>
This PR is intended to merge 4 months of work in the `nexus` feature
branch into `main`.
The functionality it brings is:
- Dispatching Nexus Tasks by namespace and task queue
- Internal implementation of the Incoming Service Registry - not yet
exposed
- Attaching workflow close callbacks on `StartWorkflowExecutionRequest`
and processing of those callbacks
There's more to come and some of the callback code will be refactored
into a new plugin architecture
(https://github.com/temporalio/temporal/pull/5446) soon.
---------
Co-authored-by: PJ Doerner <[email protected]>
## What changed?
<!-- Describe what has changed in this PR -->
Rename vars related to visibility.
## Why?
<!-- Tell your future self why have you made these changes -->
Ease to read code.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Existing unit tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No.
## 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) -->
No
## What changed?
<!-- Describe what has changed in this PR -->
Remove support for standard visibility
## Why?
<!-- Tell your future self why have you made these changes -->
Standard visibility is deprecated.
## 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? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
<!-- 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?**
<!-- Describe what has changed in this PR -->
**What changed?**
Adding ListQueues API to QueueV2 and implementing it for Cassandra and
SQL
<!-- Tell your future self why have you made these changes -->
**Why?**
This API can be used by operators to list different types of queues
including 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% 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?**
<!-- Describe what has changed in this PR -->
**What changed?**
Adding FOR UPDATE clause when fetching queueV2 metadata and removing
unused field version from queue metadata.
<!-- Tell your future self why have you made these changes -->
**Why?**
If a queueV2 metadata row is fetched in a transaction, we have to place
a lock on that row
to avoid another transaction reading from that line. This can happen
when two threads are trying to
delete messages from the queue. Two of them will update queue metadata
and write it back. This will lead
to a race condition. By adding 'FOR UPDATE' SQL clause, the first
transaction will get an exclusive lock
on the row. The second transaction will wait until the first transaction
is complete or rollback.
Also, removing the version field from QueueV2 metadata table. We will
not be using this field since we are using sql transactions.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Unit test. Executed through the debugger to make sure
SelectFromQueueV2MetadataForUpdate() is called instead of
SelectFromQueueV2Metadata() when executed inside a trancation.
<!-- 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?**
<!-- Describe what has changed in this PR -->
**What changed?**
Adding RangeDeleteMessages() and CreateQueue() methods for SQL version
of persistence.QueueV2, which supersedes the persistence.Queue
interface.
<!-- Tell your future self why have you made these changes -->
**Why?**
We plan on using this for the upcoming history task DLQ project.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Unit tests. Code has 100% unit 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?**
---------
Co-authored-by: Michael Snowden <[email protected]>
<!-- Describe what has changed in this PR -->
**What changed?**
Adding EnqueueMessage() and ReadMessage() methods for SQL version of
persistence.QueueV2, which supersedes the persistence.Queue interface.
The implementations for delete and merge are left out for now and will
be implemented later.
<!-- Tell your future self why have you made these changes -->
**Why?**
We plan on using this for the upcoming history task DLQ project.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Unit tests.
<!-- 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?**
<!-- Describe what has changed in this PR -->
**What changed?**
`Driver` interface (with two implementations) was added to the
postgresql persistence package in order to support other drivers than
`lib/pq`. Fixes https://github.com/temporalio/temporal/issues/1775
Essentially, this PR does
https://github.com/temporalio/temporal/pull/4914 in a
backward-compatible and extendable way
<!-- Tell your future self why have you made these changes -->
**Why?**
Since `lib/pq` does not support multi-node clusters
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Existing tests
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
No, since you should explicitly change the driver in your config file.
However, `connectAttributes` depend on the driver (e.g.,
`binary_parameters` is supported only by `lib/pq` and is not a part of
postresql standard), so one should be careful changing drivers in
production.
<!-- 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?**
Added double quotes around database name in the create database query
for PostgreSQL.
<!-- Tell your future self why have you made these changes -->
**Why?**
The issue has been created on temporal-operator project (see:
https://github.com/alexandrevilain/temporal-operator/issues/402).
When we try to use the `temporal-sql-tool` `create` command with a
database name containing hyphen(s), even if escaped in command, it
throws the following error: `pq: syntax error at or near \"-\"`.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
Before the fix:
```bash
$ go run ./cmd/tools/sql --endpoint="localhost" --port="5432" --user="temporal-aws-dev" --password="$TEMPORAL_DEFAULT_DATASTORE_PASSWORD" --database="temporal-aws-dev" --plugin="postgres" create
2023-08-05T20:44:58.957+0200 ERROR Unable to create SQL database. {"error": "pq: syntax error at or near \"-\"", "logging-call-at": "handler.go:94"}
exit status 1
```
After the fix:
```bash
$ go run ./cmd/tools/sql --endpoint="localhost" --port="5432" --user="temporal-aws-dev" --password="$TEMPORAL_DEFAULT_DATASTORE_PASSWORD" --database="temporal-aws-dev" --plugin="postgres" create
$ echo $?
0
```
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
Nothing.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No.
* Revert "Capture UpdateInfos in MutableState mutation (#4372)"
This reverts commit c78ee02eee.
* Revert "Adds update state indexing to MutableState (#4224)"
This reverts commit f8303d8e7e.
* Add UpdateInfo map to WorkflowExecutionInfo
This inlines the UpdateInfo index into the pre-existing execution blob
so that downstream persistence implementations won't see any change.
Add UpdateInfo records to MutableState
A mechanism for storing pointers into the workflow history representing
update accepted or completed events. Storage added for Cassandra,
PosgtreSQL, MySQL, and SQLite.
* Create base schema for PostgreSQL 12
* Changes to PostgreSQL 12 visibility schame to support advanced visibility
* Create PostgreSQL 12 db interface and configs
* Revert "Fix auth plugin configuration to match the new SQLAuthPlugin config block (#2844)"
This reverts commit 37ab2b5664.
* Revert rds-iam-auth - current drivers dont support authentication callbacks
Signed-off-by: Alexander Mays <[email protected]>
Signed-off-by: Alexander Mays <[email protected]>
Added:
A new environment variable to the CLI: SQL_AUTH_PLUGIN=rds-iam-auth
A new flag arg to the CLI: --sql-auth-plugin rds-iam-auth
2 new docker template variables: authPlugin: {{ default .Env.SQL_AUTH_PLUGIN "" }} and authPlugin: {{ default .Env.SQL_VIS_AUTH_PLUGIN "" }}
A new SQL configuration attribute authPlugin
- Range for matching GetTasks is now [inclusive, exclusive), instead of (exclusive, inclusive]
- Range for matching CompleteTasksLessThan is now < max TaskID, instead of <=
- Range for admin ListTaskQueueTasks is now [inclusive, exclusive)
- support pagination for sql GetTransfer/VisibilityTasks
- improve pagination for sql GetTimer/ReplicationTasks
- new ExecutionMutableStateTaskSuite suite
