[dependabot]

Bumps the core-go group in /apps/api with 17 updates:

Package	From	To
github.com/altcha-org/altcha-lib-go/v2	2.0.0-20260512100103-f14102c7e9bd	2.4.1
github.com/gofiber/fiber/v3	3.4.0	3.6.1
github.com/gofiber/storage/redis/v3	3.5.0	3.6.2
github.com/jackc/pgx/v5	5.10.0	5.11.0
github.com/mileusna/useragent	1.3.4	1.3.5
github.com/pressly/goose/v3	3.27.2	3.29.0
github.com/redis/go-redis/v9	9.21.0	9.23.0
github.com/riverqueue/river	0.40.0	0.49.0
github.com/riverqueue/river/riverdriver/riverpgxv5	0.40.0	0.49.0
github.com/riverqueue/river/rivertype	0.40.0	0.49.0
github.com/santhosh-tekuri/jsonschema/v6	6.0.2	6.0.3
github.com/shirou/gopsutil/v4	4.26.5	4.26.9
github.com/valyala/fasthttp	1.72.0	1.75.0
github.com/yuin/goldmark	1.8.2	1.8.6
golang.org/x/image	0.45.0	0.47.0
google.golang.org/grpc	1.83.2	1.84.0
google.golang.org/protobuf	1.36.11	1.36.12

Updates github.com/altcha-org/altcha-lib-go/v2 from 2.0.0-20260512100103-f14102c7e9bd to 2.4.1

Release notes

Sourced from github.com/altcha-org/altcha-lib-go/v2's releases.

v2.4.1

Changes:

• New (legacy v1): VerifySolutionWithResult with distinct Expired flag #11

v2.4.0

This release fixes several verification bugs, including two that could let VerifySolution accept solutions it never checked. All v2 users should upgrade. Versions v2.0.0–v2.3.0 are retracted.

Security fixes

• VerifySolution returned Verified: true without checking the solution when DeriveKey was not set and the key-signature check didn't apply. A validly signed challenge with any derivedKey was accepted.
• VerifySolution skipped the signature check entirely when HMACSignatureSecret was empty, so unsigned or forged challenges (e.g. with an attacker-chosen keyPrefix or cost) were accepted.
• CreateChallenge with Counter set but no DeriveKey produced a challenge with an empty keyPrefix, which any counter solves.

Breaking changes

• VerifySolution requires HMACSignatureSecret. It returns an error if the secret is empty.
• VerifySolution requires DeriveKey unless the challenge has a keySignature and HMACKeySignatureSecret is set. Otherwise it returns an error.
• CreateChallenge returns an error when:
  • Counter is set without DeriveKey;
  • KeyPrefix is not valid hex;
  • CounterMode is unknown.
• SolveChallenge times out after 90 seconds by default and returns nil, nil, the same as when StopChan fires. Set Timeout: -1 to restore unlimited solving.
• Expiry is enforced exactly:
  • VerifySolution compares expiresAt with sub-second precision; previously it allowed up to ~1 s past expiry.
  • Negative expiresAt values now count as expired.
  • VerifyServerSignature likewise treats a negative expire as expired.
• KeyPrefix is lowercased before the challenge is signed. Prefix matching ignores case.
• No keySignature on unsigned challenges. When CreateChallenge gets no HMACSignatureSecret, it no longer adds a keySignature.
• Zero-valued parameters are part of the signature. memoryCost, parallelism and expiresAt sent as 0 or null are now included when the signature is checked, as in altcha-lib (JS). Adding such keys to a Go-signed challenge now makes verification fail; previously they were silently dropped.
• Go 1.25 or newer is required (go 1.25.0 in go.mod, as required by golang.org/x/crypto).

Fixes

• Challenges created by altcha-lib (JS) with memoryCost, parallelism or expiresAt set to 0 or null now verify.
• A malformed solution.derivedKey (non-hex or odd length) on the key-signature path now gives InvalidSolution: true instead of an error, so a bad client payload no longer causes a server error.
• KeyPrefixLength larger than the derived key no longer panics. The prefix is capped at the full key.
• Nonce and salt are now 16 random bytes, matching altcha-lib. Challenges issued with 12-byte values still verify.

New features

• CounterMode option on CreateChallengeOptions, SolveChallengeOptions and VerifySolutionOptions:
  • CounterModeUint32: the default, unchanged behaviour.
  • CounterModeString: appends the counter as a decimal string; compatible with altcha-lib's counterMode: 'string'.
• Timeout option on SolveChallengeOptions: zero means the 90 s default; a negative value disables it.

Versioning

• v2 releases are now tagged v2.x.y (previously v2/v2.x.y), so go get and the Go module proxy can resolve them: go get github.com/altcha-org/altcha-lib-go/v2@v2.4.0

... (truncated)

Commits

• See full diff in compare view

Updates github.com/gofiber/fiber/v3 from 3.4.0 to 3.6.1

Release notes

Sourced from github.com/gofiber/fiber/v3's releases.

v3.6.1

🧹 Updates

• Consolidate media-type parameter parsing into internal/mediatype (#4750)
• Fix modernize and revive lint issues (#4759)

🐛 Fixes

• Fix client, session, basicauth and other bugs found in the audit (#4752)

🛠️ Maintenance

• bump github.com/gofiber/utils/v2 from 2.6.1 to 2.6.2 (#4760)
• bump github.com/klauspost/compress from 1.20.1 to 1.20.3 (#4757)
• bump github.com/molecule-man/go-brrr from 1.2.0 to 1.3.0 (#4758)
• bump the golang-modules group with 3 updates (#4755)
• bump release-drafter/release-drafter from 7.9.0 to 7.10.0 (#4756)
• bump actions/setup-node from 7.0.0 to 7.1.0 (#4754)

📚 Documentation

• Sync the documentation with the v3.6.0 code (#4751)

📒 Documentation: https://docs.gofiber.io/

💬 Discord: https://gofiber.io/discord

Full Changelog: gofiber/fiber@v3.6.0...v3.6.1

Thank you @​alexandear, @​gaby, @​ninadsutrave and @​ReneWerner87 for making this release possible.

v3.6.0

⚡ Performance

Fiber v3.6.0 ships with fasthttp v1.75.0. With it, Fiber v3 is back on par with the speed of v2, despite the additional security mechanisms built in since then.

Time per request vs. v2	v3.5.0 (fasthttp v1.73.0)	v3.6.0 (fasthttp v1.75.0)
fasthttp only	+18%	-5%
Static route	+16%	-14%
Route parameter	+15%	-13%
Middleware chain	+13%	-12%
Header lookup	+29%	+3%
Locals	+33%	+5%
JSON response	+6%	-3%
JSON bind	+14%	-2%
Median of all 22 scenarios	+10%	-5%

Negative is faster than v2. v3.6.0 was measured on main three days before the release. All scenarios are published on our benchmarks page, where we now continuously make sure that v3 does not get slower again.

... (truncated)

Commits

• e09ba68 chore: bump version to v3.6.1
• b06eee1 Merge pull request #4752 from gofiber/fix/audit-code-issues
• 3291357 🐛 bug: fix client, session, basicauth and other bugs found in the docs audit
• e090d85 📒 docs: sync the documentation with the v3.6.0 code
• 9d6d7b6 Merge pull request #4750 from ninadsutrave/chore/internal-mediatype
• 7db2534 Merge pull request #4760 from gofiber/dependabot/go_modules/github.com/gofibe...
• 70d6e0f build(deps): bump github.com/gofiber/utils/v2 from 2.6.1 to 2.6.2
• ccbded0 chore(ci): trigger dependabot after gofiber/utils release [skip ci]
• 4106047 Merge pull request #4759 from alexandear-org/refactor/update-golangci-lint-2-14
• 66ac88f ♻️ refactor: modernize code
• Additional commits viewable in compare view

Updates github.com/gofiber/storage/redis/v3 from 3.5.0 to 3.6.2

Release notes

Sourced from github.com/gofiber/storage/redis/v3's releases.

redis - v3.6.2

🛠️ Maintenance

• bump the docker-modules group across 3 directories with 2 updates (#3530)
• bump github.com/Microsoft/go-winio from 0.6.2 to 0.6.3 in /redis (#3542)
• bump github.com/redis/go-redis/v9 from 9.22.0 to 9.23.0 in /redis in the go-redis-modules group across 1 directory (#3509)
• bump the opentelemetry-modules group across 3 directories with 4 updates (#3502)
• bump the docker-modules group across 3 directories with 2 updates (#3493)
• bump the shirou-modules group across 3 directories with 1 update (#3480)
• bump the klauspost-modules group across 4 directories with 1 update (#3461)

Full Changelog: gofiber/storage@redis/v3.6.1...redis/v3.6.2

Thank you @​ReneWerner87 for making this update possible.

redis - v3.6.1

🛠️ Maintenance

• bump the ebitengine-modules group across 3 directories with 1 update (#3433)
• bump go.uber.org/atomic from 1.11.0 to 1.12.0 in /redis (#3420)
• bump github.com/magiconair/properties from 1.18.11 to 1.18.12 in /redis (#3401)
• bump the docker-modules group across 3 directories with 2 updates (#3364)
• bump the golang-modules group across 5 directories with 4 updates (#3360)
• bump the golang-modules group across 3 directories with 1 update (#3335)
• bump the docker-modules group across 3 directories with 2 updates (#3341)
• bump the klauspost-modules group across 4 directories with 1 update (#3322)
• bump the ebitengine-modules group across 3 directories with 1 update (#3314)

Full Changelog: gofiber/storage@redis/v3.6.0...redis/v3.6.1

Thank you @​ReneWerner87 for making this update possible.

redis - v3.6.0

🚀 New

• add NewFromConnection to build every storage on an existing connection (#3226)

🛠️ Maintenance

... (truncated)

Commits

• 25f84fc Merge pull request #3576 from gofiber/dependabot/go_modules/s3/golang-modules...
• 197786d chore(deps): bump the golang-modules group across 5 directories with 2 updates
• 1d1d095 Merge pull request #3582 from gofiber/dependabot/go_modules/cassandra/klauspo...
• 7829e01 Merge pull request #3585 from gofiber/dependabot/go_modules/s3/klauspost-modu...
• dc45031 Merge pull request #3584 from gofiber/dependabot/go_modules/s3/aws-modules-f9...
• 7e625f9 Merge pull request #3583 from gofiber/dependabot/go_modules/cassandra/softwar...
• bafeb18 Merge pull request #3581 from gofiber/dependabot/go_modules/dynamodb/aws-modu...
• 7b29442 chore(deps): bump the klauspost-modules group across 5 directories with 1 update
• 6fd6cd0 chore(deps): bump the aws-modules group across 1 directory with 19 updates
• 02a8630 chore(deps): bump software.sslmate.com/src/go-pkcs12 in /cassandra
• Additional commits viewable in compare view

Updates github.com/jackc/pgx/v5 from 5.10.0 to 5.11.0

Release notes

Sourced from github.com/jackc/pgx/v5's releases.

v5.11.0

This release adds direct PostgreSQL type scanning through database/sql on Go 1.27, improves compatibility with libpq connection strings and PostgreSQL date/time values, and includes further decoder hardening. See Changes for connection-string and date/time behavior changes that may affect existing applications.

Features

• stdlib: support Go 1.27's driver.RowsColumnScanner, allowing PostgreSQL types such as arrays and ranges to be scanned directly into Go values without pgtype.Map.SQLScanner. Existing database/sql scalar conversions and sql.Scanner behavior are preserved. The minimum supported Go version remains 1.25.
• Add Rows.TypeMap to expose the type map used to decode rows, including rows created by RowsFromResultReader that have no underlying Conn. Custom implementations of Rows, including mocks, must add this method.
• pgconn: add Config.MaxProtocolMessageBodyLen to configure the maximum incoming protocol message body size (carter-ya)
• pgconn: add ErrReadOnlyConnection, ErrReadWriteConnection, ErrPrimaryConnection, and ErrStandbyConnection sentinel errors for target_session_attrs validation, allowing callers to use errors.Is (Adrian-Stefan Mares)
• pgxpool: accept pool_ping_timeout in connection strings to configure Config.PingTimeout. The default is zero; zero and negative durations mean no timeout (1991santhu)

Changes

• Name-based row-to-struct mapping now matches explicit db tags case-insensitively, with exact matches taking precedence so tags can still distinguish quoted column names that differ only by case (AlisinaDevelo)

• pgconn: resolve the OS user account only when no user is supplied by the connection string, environment, or service file, avoiding unnecessary account lookups and crashes in some restricted container environments. Home-directory defaults for password, service, and TLS files remain available independently of the account lookup. On Unix these now use $HOME rather than the OS account's home directory (Mohamed MAACHE)

• pgtype: date, timestamp and timestamptz text values are now parsed and written by a hand-written parser and encoder for PostgreSQL's ISO date/time format instead of time.Parse and time.Format. Go's layout language cannot express a variable-width year or the BC era, which is the root of the bugs below. The text scan path is roughly 2.5x faster for timestamp and timestamptz. Bug fixes:

  • timestamp and timestamptz no longer silently move February 29 of a BC leap year to March 1 when encoding. time.Date(-4712, 2, 29, ...) was written as 4713-03-01 BC and is now written as 4713-02-29 BC. This affected ordinary four-digit BC years, not only extended-range ones. date was never affected.
  • timestamp and timestamptz can now scan BC leap days. 4713-02-29 BC previously failed with day out of range. date could already scan them.
  • Years past 9999 can now be scanned. 10000-01-02 03:04:05 previously failed to parse, so timestamp and timestamptz values at the high end of PostgreSQL's range were unreadable over the simple protocol and in any other text-format result.
  • time.Time arguments in the simple protocol now encode BC dates correctly, using the same timestamp encoder.
  • Fractional seconds beyond microsecond precision are rounded the way the server rounds them (round half to even, carrying into the rest of the value) instead of being kept at full precision. PostgreSQL never sends more than six fractional digits, so this only affects values from other sources.

  Behavior changes:

  • date now rejects impossible dates instead of normalizing them. 2024-02-30 returned 2024-03-01 and 2024-13-01 returned 2025-01-01; both are now errors. timestamp and timestamptz already rejected them.
  • All three types now reject values outside PostgreSQL's range for that type, in the binary format as well as the text format. PostgreSQL never sends out-of-range dates, so this only affects corrupt or hand-built input; the range

... (truncated)

Changelog

Sourced from github.com/jackc/pgx/v5's changelog.

5.11.0 (September 7, 2026)

This release adds direct PostgreSQL type scanning through database/sql on Go 1.27, improves compatibility with libpq connection strings and PostgreSQL date/time values, and includes further decoder hardening. See Changes for connection-string and date/time behavior changes that may affect existing applications.

Features

• stdlib: support Go 1.27's driver.RowsColumnScanner, allowing PostgreSQL types such as arrays and ranges to be scanned directly into Go values without pgtype.Map.SQLScanner. Existing database/sql scalar conversions and sql.Scanner behavior are preserved. The minimum supported Go version remains 1.25.
• Add Rows.TypeMap to expose the type map used to decode rows, including rows created by RowsFromResultReader that have no underlying Conn. Custom implementations of Rows, including mocks, must add this method.
• pgconn: add Config.MaxProtocolMessageBodyLen to configure the maximum incoming protocol message body size (carter-ya)
• pgconn: add ErrReadOnlyConnection, ErrReadWriteConnection, ErrPrimaryConnection, and ErrStandbyConnection sentinel errors for target_session_attrs validation, allowing callers to use errors.Is (Adrian-Stefan Mares)
• pgxpool: accept pool_ping_timeout in connection strings to configure Config.PingTimeout. The default is zero; zero and negative durations mean no timeout (1991santhu)

Changes

• Name-based row-to-struct mapping now matches explicit db tags case-insensitively, with exact matches taking precedence so tags can still distinguish quoted column names that differ only by case (AlisinaDevelo)

• pgconn: resolve the OS user account only when no user is supplied by the connection string, environment, or service file, avoiding unnecessary account lookups and crashes in some restricted container environments. Home-directory defaults for password, service, and TLS files remain available independently of the account lookup. On Unix these now use $HOME rather than the OS account's home directory (Mohamed MAACHE)

• pgtype: date, timestamp and timestamptz text values are now parsed and written by a hand-written parser and encoder for PostgreSQL's ISO date/time format instead of time.Parse and time.Format. Go's layout language cannot express a variable-width year or the BC era, which is the root of the bugs below. The text scan path is roughly 2.5x faster for timestamp and timestamptz. Bug fixes:

  • timestamp and timestamptz no longer silently move February 29 of a BC leap year to March 1 when encoding. time.Date(-4712, 2, 29, ...) was written as 4713-03-01 BC and is now written as 4713-02-29 BC. This affected ordinary four-digit BC years, not only extended-range ones. date was never affected.
  • timestamp and timestamptz can now scan BC leap days. 4713-02-29 BC previously failed with day out of range. date could already scan them.
  • Years past 9999 can now be scanned. 10000-01-02 03:04:05 previously failed to parse, so timestamp and timestamptz values at the high end of PostgreSQL's range were unreadable over the simple protocol and in any other text-format result.
  • time.Time arguments in the simple protocol now encode BC dates correctly, using the same timestamp encoder.
  • Fractional seconds beyond microsecond precision are rounded the way the server rounds them (round half to even, carrying into the rest of the value) instead of being kept at full precision. PostgreSQL never sends more than six fractional digits, so this only affects values from other sources.

  Behavior changes:

  • date now rejects impossible dates instead of normalizing them. 2024-02-30 returned 2024-03-01 and 2024-13-01 returned 2025-01-01; both are now errors. timestamp and timestamptz already rejected them.
  • All three types now reject values outside PostgreSQL's range for that type, in the binary format as well as the

... (truncated)

Commits

• 5e583fa Update changelog for v5.11.0
• 3927116 Apply gofumpt formatting required by lint
• eb07165 Quote filesystem paths in development connection strings
• cf5938f Allow unsigned digit counts in binary numeric encoding
• 3930cf5 Accept PostgreSQL POSIX timezone offsets in text timestamps
• 93261be Prefer exact db tag matches when mapping rows to structs
• e8d8ad1 Merge pull request #2647 from sueun-dev/fix-range-text-quoting-20260906
• 01d2fd3 Merge pull request #2644 from eliranbz/fix-failed-prepare-deallocation
• 9b7e3be Merge pull request #2645 from ash2k/move-channel
• 76d78f5 Merge pull request #2643 from AshSgDe29071999/fix/hstore-pairs-estimate-clamp
• Additional commits viewable in compare view

Updates github.com/mileusna/useragent from 1.3.4 to 1.3.5

Release notes

Sourced from github.com/mileusna/useragent's releases.

v1.3.5

Performance improvements

Commits

• 8bf5b3a Bytespider fix
• 5cdf957 Merge branch 'pr/wolfeidau/40'
• bff4f0e Merge branch 'pr/DaniruKun/46'
• af0d3cb Refactoring
• 5331aef Bug-fix
• df8f29e Move func
• 30a7616 Performance improvements
• 13c98cc Refactoring
• 704ef69 Add better detection for Samsung Browser
• 343162a Use tablet constant
• Additional commits viewable in compare view

Updates github.com/pressly/goose/v3 from 3.27.2 to 3.29.0

Release notes

Sourced from github.com/pressly/goose/v3's releases.

v3.29.0

Added

• Support environ credentials for YDB using connection string parameter use_env_credentials.

Changed

• Various dependency upgrades

v3.28.0

Added

• CLI: azuresql driver for Azure SQL with Microsoft Entra ID (Azure AD) authentication via fedauth connection string parameters, e.g. goose azuresql "sqlserver://host?database=mydb&fedauth=ActiveDirectoryDefault" status. Excluded when building with the no_mssql or no_azuresql tags (#1109)
• MySQL/MariaDB table-based Locker via lock.NewMySQLTableLocker, the MySQL counterpart to the Postgres table locker from #993, accepting the same TableLockerOption set (#1075)

Changed

• Minimum Go version is now 1.26
• ClickHouse: new goose_db_version tables are created with ORDER BY (version_id) instead of ORDER BY (date). Existing tables are unchanged (#1085)
• MySQL/TiDB: the tstamp column is now DATETIME instead of TIMESTAMP, which is capped at 2038-01-19 (#1053). Only newly created tables are affected; existing tables can be updated with:

  ALTER TABLE goose_db_version MODIFY tstamp datetime NULL DEFAULT CURRENT_TIMESTAMP;

• Various dependency upgrades

Fixed

• goose create returns a clear "file exists" error, including the path, instead of %!w(<nil>) when the migration file already exists (#1104)

v3.27.3

Changed

• Various dependency upgrades

Changelog

Sourced from github.com/pressly/goose/v3's changelog.

[v3.29.0] - 2026-10-11

Added

• Support environ credentials for YDB using connection string parameter use_env_credentials.

Changed

• Various dependency upgrades

[v3.28.0] - 2026-09-02

Added

• CLI: azuresql driver for Azure SQL with Microsoft Entra ID (Azure AD) authentication via fedauth connection string parameters, e.g. goose azuresql "sqlserver://host?database=mydb&fedauth=ActiveDirectoryDefault" status. Excluded when building with the no_mssql or no_azuresql tags (#1109)
• MySQL/MariaDB table-based Locker via lock.NewMySQLTableLocker, the MySQL counterpart to the Postgres table locker from #993, accepting the same TableLockerOption set (#1075)

Changed

• Minimum Go version is now 1.26

• ClickHouse: new goose_db_version tables are created with ORDER BY (version_id) instead of ORDER BY (date). Existing tables are unchanged (#1085)

• MySQL/TiDB: the tstamp column is now DATETIME instead of TIMESTAMP, which is capped at 2038-01-19 (#1053). Only newly created tables are affected; existing tables can be updated with:

  ALTER TABLE goose_db_version MODIFY tstamp datetime NULL DEFAULT CURRENT_TIMESTAMP;

• Various dependency upgrades

Fixed

• goose create returns a clear "file exists" error, including the path, instead of %!w(<nil>) when the migration file already exists (#1104)

[v3.27.3] - 2026-07-22

Changed

• Various dependency upgrades

Commits

• 8b457ba release: v3.29.0
• 4dc946a chore: update Go dependencies (#1140)
• c088af3 ydb: adds environ credentials support (#1062)
• 0e5c23d docs: show env command in CLI help (#1132)
• d832df3 Send goose version in YDB build-info header (#1063)
• d181bdb docs: document ClickHouse dialect (#1127)
• 43d2d9c release: v3.28.0
• c65c559 docs: update changelog
• 674e150 fix: use DATETIME instead of TIMESTAMP for MySQL/TiDB tstamp column (Y2K38) (...
• f604e88 fix: include path in duplicate migration file error and use 0666 mode
• Additional commits viewable in compare view

Updates github.com/redis/go-redis/v9 from 9.21.0 to 9.23.0

Release notes

Sourced from github.com/redis/go-redis/v9's releases.

9.23.0

This is a minor release. It contains everything from 9.23.0-beta.1, so these notes cover the full 9.22.0 → 9.23.0 upgrade.

⚠️ Changes to check when you upgrade from 9.22.0:

• Go 1.26 is now the minimum Go version (#4060). The go directive of the root module and of the submodules moved from 1.24 to 1.26, as part of the dependency bumps for govulncheck findings. Projects that build with Go 1.24 or 1.25 must upgrade the toolchain.
• Each Client has a dedicated pipeline connection pool (#4002). This includes failover clients and cluster node clients. Pipeline, TxPipeline, and autopipeline operations use this pool, so they do not compete with regular commands for main-pool connections. The pool is for burst capacity only: it dials only when necessary, an unused pool holds zero connections, and if the pool is full an operation uses the main pool. Set PipelinePoolSize: -1 to get the previous single-pool behavior.
• AutoPipelineOptions.MaxBatchBytes has a default of 128 KiB (before, there was no limit). The default prevents a write/reply deadlock; it is not a throughput control. The buffers of the pipeline pool also have a default of 128 KiB.

⚠️ Changes to experimental APIs since 9.23.0-beta.1 (no effect if you upgrade from 9.22.0):

• AutoPipelineOptions.FullDuplexFastSubmit is removed (#4018). The submit channel is replaced by a queue that takes a full wave of commands in one lock, so the separate fast path is not necessary. Remove the field from your options.
• Options.ClientSideCacheRefreshRecencyWindow is removed (#4034). Refresh-on-invalidate now reads again every cached entry of an invalidated key and does not look at how recently the entry was read. On a write-heavy keyspace this means refresh traffic across the full resident cache. Remove the field from your options.
• LocalCache.LRUClock() is removed (#4034). It returned the recency token that the removed recency window used, and has no replacement. Remove calls to it.
• ClientSideCacheInvalidationBatchWindow served stale values in beta.1 (#4033). Under load the batcher applied only ~15% of invalidations, and the cache served invalidated values with a ~100% hit rate. 9.23.0 applies all of them. If you used this option on beta.1, upgrade.

🚀 Highlights

Full-Duplex Auto-Pipelining (Experimental)

Set AutoPipelineOptions.FullDuplex to enable the full-duplex mode of the automatic pipeliner. The default mode sends one batch per round trip. In full-duplex mode the engine holds one pipeline-pool connection, and a writer goroutine and a reader goroutine move the ordered command stream in both directions at the same time. On a high-latency link each command completes in approximately one round-trip time (RTT) on a single connection. On a 50 ms WAN profile: ~389k ops/s at 52 ms p50, against ~207k ops/s at 116 ms on the half-duplex ordered path.

The mode works on both faces of a standalone Client (AutoPipeline() and AsyncAutoPipeline()), and natively on a ClusterClient when routing goes to masters only. On a cluster, one child engine per master sends each command to the node that owns its slot, and follows MOVED / ASK redirects and retryable replies (LOADING, READONLY, ...) through the usual cluster redirect path. With replica routing (ReadOnly, RouteByLatency, or RouteRandomly), the autopipeliner uses the half-duplex shard flushers, which obey the shard picker. Config().FullDuplex reports the mode in effect.

Options:

• FullDuplexWindow — the maximum number of commands in flight (backpressure).
• FullDuplexIdleTimeout and FullDuplexMaxHold — when the engine returns the held connection to the pool. The pool hooks then do re-authentication and maintenance-notification handoffs.
• MaxFlushDelay — now also used in full-duplex mode (#4014). The writer waits only when enough commands are in flight, so low-concurrency callers keep the 1×RTT behavior. With MaxFlushDelay=250µs at 1024 callers: +22% ops/s and −26% p99. The default is 0, so this is opt-in.
• NumShards — on a standalone Client, the number of full-duplex engines (#4022). See below.

Pipeline() on the full-duplex connection (#4021). Standalone Client only. Before, ap.Pipeline() used a pooled connection for each Exec. It now submits the batch to the engine as one contiguous run (FDPipelined), so replies come back in submit order, as on a dedicated connection. At 256–1024 callers with 10 commands per Exec: +49% to +52% throughput on one socket instead of ~150. Errors, retries, hooks, and metrics behave like an ordinary pipeline. A batch that cannot use the stream (a blocking command, a per-command read timeout, a diverted command, or a batch larger than the queue) falls back to the ordinary pipeline. TxPipeline stays on a pooled connection, because MULTI/EXEC needs connection affinity. On a ClusterClient, ap.Pipeline() is still the ordinary cluster pipeline. A batch that the queue cannot admit now reserves its slots and waits in a first-come line, so single commands cannot starve a long pipeline (#4057, merged as part of #4021) by @​vlady-kotsev.

Several engines on one client (#4022). With FullDuplex, NumShards > 1 now means N engines on one client: one pool, one hook chain, N held connections. Commands route by a hash of their first key, so commands on the same key stay on one connection and keep their order without Unordered. Keyless commands are distributed round-robin. An FDPipelined batch stays on one engine. The pipeline pool must hold at least NumShards connections for each full-duplex autopipeliner. More engines help only under high concurrency: with 10-command pipelines, 8 engines were 30% slower than 1 at 8 callers, equal at about 128 callers, and 2.2× faster at 1024 callers.

The full-duplex path supports blocking commands, Options.Limiter (one admission per written batch), per-command and pipeline hooks, OTel metrics, retry budgets (a NoRetry command is never sent again after it is on the wire), and seamless maintenance handoffs. Limits of the stream model:

• A hook can observe a command, but cannot stop it. A ProcessHook that returns without calling next does not cancel the command on the full-duplex path; the command is already queued on the held connection. Run policy or kill-switch hooks on a plain client or on the half-duplex autopipeliner.
• Diverted commands are not ordered with the stream. The engine diverts blocking commands, connection-hostile commands, and managed HIMPORT commands. On the async face, wait for the result of a diverted command before you submit a command that depends on it.
• Single commands on the full-duplex stream do not use the client-side cache. If CSC is enabled, a cacheable command on the stream does not read or write the cache.
• Duration metrics are recorded per reply. A command that fails before it reaches the reader (lease failure, limiter denial, retry exhaustion, close) calls the error callback but records no operation-duration sample.

rdb := redis.NewClient(&redis.Options{
	Addr: "localhost:6379",
	AutoPipelineOptions: &redis.AutoPipelineOptions{
		FullDuplex: true, // stream commands on one held connection, ~1 RTT each
	},
})
defer rdb.Close()
</tr></table> 

... (truncated)

Changelog

Sourced from github.com/redis/go-redis/v9's changelog.

9.23.0 (2026-10-05)

This is a minor release. It contains everything from 9.23.0-beta.1, so these notes cover the full 9.22.0 → 9.23.0 upgrade. The release adds:

• An experimental full-duplex mode for the automatic pipeliner, now with Pipeline() on the full-duplex connection and several engines on one client.
• Refresh-on-invalidate and miss coalescing for client-side caching, and a faster cache read path.
• Better distribution of cluster reads under latency-based routing.
• Client.EphemeralConn, an opt-in limit on queued autopipeline commands, and many stability fixes.

⚠️ Changes to check when you upgrade from 9.22.0:

• Go 1.26 is now the minimum Go version (#4060). The go directive of the root module and of the submodules moved from 1.24 to 1.26, as part of the dependency bumps for govulncheck findings. Projects that build with Go 1.24 or 1.25 must upgrade the toolchain.
• Each Client has a dedicated pipeline connection pool (#4002). This includes failover clients and cluster node clients. Pipeline, TxPipeline, and autopipeline operations use this pool, so they do not compete with regular commands for main-pool connections. The pool is for burst capacity only: it dials only when necessary, an unused pool holds zero connections, and if the pool is full an operation uses the main pool. Set PipelinePoolSize: -1 to get the previous single-pool behavior.
• AutoPipelineOptions.MaxBatchBytes has a default of 128 KiB (before, there was no limit). The default prevents a write/reply deadlock; it is not a throughput control. The buffers of the pipeline pool also have a default of 128 KiB.

⚠️ Changes to experimental APIs since 9.23.0-beta.1 (no effect if you upgrade from 9.22.0):

• AutoPipelineOptions.FullDuplexFastSubmit is removed (#4018). The submit channel is replaced by a queue that takes a full wave of commands in one lock, so the separate fast path is not necessary. Remove the field from your options.
• Options.ClientSideCacheRefreshRecencyWindow is removed (#4034). Refresh-on-invalidate now reads again every cached entry of an invalidated key and does not look at how recently the entry was read. On a write-heavy keyspace this means refresh traffic across the full resident cache. Remove the field from your options.
• LocalCache.LRUClock() is removed (#4034). It returned the recency token that the removed recency window used, and has no replacement. Remove calls to it.
• ClientSideCacheInvalidationBatchWindow served stale values in beta.1 (#4033). Under load the batcher applied only ~15% of invalidations, and the cache served invalidated values with a ~100% hit rate. 9.23.0 applies all of them. If you used this option on beta.1, upgrade.

🚀 Highlights

Full-Duplex Auto-Pipelining (Experimental)

Set AutoPipelineOptions.FullDuplex to enable the full-duplex mode of the automatic pipeliner. The default mode sends one batch per round trip. In full-duplex mode the engine holds one pipeline-pool connection, and a writer goroutine and a reader goroutine move the ordered command stream in both directions at the same time. On a high-latency link each command completes in approximately one round-trip time (RTT) on a single connection. On a 50 ms WAN profile: ~389k ops/s at 52 ms p50, against ~207k ops/s at 116 ms on the half-duplex ordered path.

The mode works on both faces of a standalone Client (AutoPipeline() and AsyncAutoPipeline()), and natively on a ClusterClient when routing goes to masters only. On a cluster, one child engine per master sends each command to the node that owns its slot, and follows MOVED / ASK redirects and retryable replies (LOADING, READONLY, ...) through the usual cluster redirect path. With replica routing (ReadOnly, RouteByLatency, or RouteRandomly), the autopipeliner uses the half-duplex shard flushers, which obey the shard picker. Config().FullDuplex reports the mode in effect.

Options:

• FullDuplexWindow — the maximum number of commands in flight (backpressure).
• FullDuplexIdleTimeout and FullDuplexMaxHold — when the engine returns the held connection to the pool. The pool hooks then do re-authentication and maintenance-notification handoffs.
• MaxFlushDelay — now also used in full-duplex mode (#4014). The writer waits only when enough commands are in flight, so low-concurrency callers keep the 1×RTT behavior. With MaxFlushDelay=250µs at 1024 callers: +22% ops/s and −26% p99. The default is 0, so this is opt-in.
• NumShards — on a standalone Client, the number of full-duplex engines (#4022). See below.

Pipeline() on the full-duplex connection (#4021). Standalone Client only. Before, ap.Pipeline() used a pooled connection for each Exec. It now submits the batch to the engine as one contiguous run (FDPipelined), so replies come back in submit order, as on a dedicated connection. At 256–1024 callers with 10 commands per Exec: +49% to +52% throughput on one socket instead of ~150. Errors, retries, hooks, and metrics behave like an ordinary pipeline. A batch that cannot use the stream (a blocking command, a per-command read timeout, a diverted command, or a batch larger than the queue) falls back to the ordinary pipeline. TxPipeline stays on a pooled connection, because MULTI/EXEC needs connection affinity. On a ClusterClient, ap.Pipeline() is still the ordinary cluster pipeline. A batch that the queue cannot admit now reserves its slots and waits in a first-come line, so single commands cannot starve a long pipeline (#4057, merged as part of #4021) by @​vlady-kotsev.

Several engines on one client (#4022). With FullDuplex, NumShards > 1 now means N engines on one client: one pool, one hook chain, N held connections. Commands route by a hash of their first key, so commands on the same key stay on one connection and keep their order without Unordered. Keyless commands are distributed round-robin. An FDPipelined batch stays on one engine. The pipeline pool must hold at least NumShards connections for each full-duplex autopipeliner. More engines help only under high concurrency: with 10-command pipelines, 8 engines were 30% slower than 1 at 8 callers, equal at about 128 callers, and 2.2× faster at 1024 callers.

The full-duplex path supports blocking commands, Options.Limiter (one admission per written batch), per-command and pipeline hooks, OTel metrics, retry budgets (a NoRetry command is never sent again after it is on the wire), and seamless maintenance handoffs. Limits of the stream model:

• A hook can observe a command, but cannot stop it. A ProcessHook that returns without calling next does not cancel the command on the full-duplex path; the command is already queued on the held connection. Run policy or kill-switch hooks on a plain client or on the half-duplex autopipeliner.
• Diverted commands are not ordered with the stream. The engine diverts blocking commands, connection-hostile commands, and managed HIMPORT commands. On the async face, wait for the result of a diverted command before you submit a command that depends on it.
• Single commands on the full-duplex stream do not use the client-side cache. If CSC is enabled, a cacheable command on the stream does not read or write the cache.
• Duration metrics are recorded per reply. A command that fails before it reaches the reader (lease failure, limiter denial, retry exhaustion, close) calls the error callback but records no operation-duration sample.

rdb := redis.NewClient(&redis.Options{
</tr></table> 

... (truncated)

Commits

• 6f2b263 chore(release): v9.23.0 (#4074)
• ec50c69 feat(conn): add DisposableConn to discard on Close (#4039)
• e3d2548 fix(pool): fix ConnStateMachine waiter races (#4072)
• 2ee6d86 fix(pool): wake waiters when a connection is released to the pool (#4028)
• 83d45ed fix:(proto): support uintptr in WriteArg (#4054)
• c2002af docs(example): add full-duplex examples (#4061)
• b5f8864 feat(autopipeline): add MaxQueuedCommands hard limit (#4070)
• 89ecbc5 fix(options): reject invalid skip_verify values in ParseURL (#4064)
• f813adc feat(autopipeline): run N full-duplex engines on one client (#4022)
• 349bcf4 feat(autopipeline): run Pipeline on the full-duplex connection (#4021)
• Additional commits viewable in compare view

Updates github.com/riverqueue/river from 0.40.0 to 0.49.0

Release notes

Sourced from github.com/riverqueue/river's releases.

v0.49.0

⚠️ If using River Pro, make sure to upgrade it to at least River Pro v0.32.0 to get a compatible package.

Changed

• Internal transaction helpers now reuse existing transactions instead of creating unnecessary savepoints. Callers of transactional APIs must roll back their transaction on error; applications that need partial rollback can create an explicit savepoint around the River call. Set RIVER_USE_LEGACY_SUBTRANSACTIONS=1 (or true) before starting the application to restore savepoints in these helpers, including those used by River Pro. This is a temporary compatibility fallback planned for removal in a future release. [PR #1420](riverqueue/river#1420).

Fixed

• Fixed rivertest.Worker to honor a configured Config.JobStuckThreshold for stuck job detection. Previously, it always used an internal 5 second threshold, so the Job appears to be stuck log line was emitt...

  Description has been truncated