Currently there is no way to set `RedisConnection`'s `onUnexpectedClosure` for connections within a `RedisConnectionPool`. This PR adds a new closure to `RedisConnectionPool.onUnexpectedConnectionClose` which will be triggered for every pool connection that closed unexpectedly.
## Motivation
Since Redis 6.0, a new serialization protocol format (v3) is available that gives richer semantic reasoning behind the different types to enable commands to better understand the return types to provide in their programming language.
In addition, the `RESPTranslator` type is going to see more direct usage, and the current API doesn't make read well.
## Changes
- Add: Internal `RESPVersion` enum that the `RESPTranslator` will start to use
- Rename: `RESPTranslator.parseBytes` to `RESPTranslator.read(from:)`
Motivation
Right now the PubSub handlers are split into three separate closures, with the subscribe/unsubscribe handlers being optional. This won't play well with AsyncStream for being able to respond to all events that a PubSub subscription can cause.
Additionally, the current structure is very verbose in code to maintain - but also adds complexity to developers who are first getting started to understand the lifecycle of PubSub events.
Changes
- Add: New `RedisPubSubEvent` enum that captures the subscribe, unsubscribe, and message lifecycle events
- Add: New `RedisPubSubEventReceiver` that combines the previous 3 closure types
- Add: Dedicated DocC Symbol Extension file for `RedisPubSubHandler`
- Change: `RedisClient.subscribe` and `RedisClient.psubscribe` method signatures to only require a single unlabeled closure
- Rename: `RedisUnsubscribeEventSource` to `RedisPubSubEvent.UnsubscribeEventSource`
- Remove: `RedisSubscriptionMessageReceiver`, `RedisSubscriptionChangeDetails`, `RedisSubscribeHandler`, and `RedisUnsubscribeHandler` types
Result
Developers should have a much easier time getting started and understanding PubSub with assistance from the compiler with types to understand
what they're being given and what's available to them as information to make more informed decisions in their app logic.
Motivation:
To maintain quality, automated code coverage reports should be generated and archived as build artifacts in CI pipelines.
Modifications:
Update CI config to run a job for running unit tests with code coverage, and exporting the report to GitLab.
Result:
Code coverage will be tracked and history recorded to compare individual code changes.
## Motivation
The API for establishing the configuration of a connection pool had a lot of jargon and properties that developers had issues keeping straight and understanding what each does.
This commit provides first-class API support for concepts such as retry strategies, and how the pool handles connection counts.
## Changes
- Add: New ConnectionCountBehavior for determining leaky / non-leaky behavior
- Add: New ConnectionRetryStrategy for allowing customization of retry behavior
- Change: RedisConnection.defaultPort to be a computed property
- Change: The logging keys of pool connection retry metadata
- Rename: Several configuration properties to drop prefixes or to be combined into new structures
## Result
Developers should have a much better experience exploring the available configuration options for pools and connections, being able to understand how each piece works with the underlying system.
There are many times that developers want exact control over which EventLoop will be executing their chained EventLoopFuture callbacks
and which Logger will do the logging in calls deep within RediStack.
All commands will now accept an optional EventLoop and Logger to hop to, and using the logger for desired logs.
Motivation:
Following the SSWG guidelines for libraries and log levels, because much of the library's behavior is expressed in the language and NIO framework as errors and failed ELFs, logging at error is "verbose" and takes away control from developers.
Modifications:
Log messages have been adjusted to more accurately represent when and how the log message should be used, especially when ELFs are failed or errors are thrown.
Result:
Developers won't have log messages at error or critical unless they opt-in from their own code, unless the library has no way of expressing the failure condition through the language.
Marius Seufzer
Gwynne Raskind
Nathan Harris
Fabian Fett
Nathan Harris
Michael Stegeman
Daniel Ramteke
Peter Adams