Repository navigation
fix(deps): update gomod dependencies - #4891
Conversation
ℹ️ Artifact update noticeFile name: flow/go.modIn order to perform the update(s) described in the table above, Renovate ran the
Due to Go's usage of Minimal Version Selection (MVS), these packages have been updated to the minimum version available, so will still abide by Details:
File name: flow/pkg/go.modIn order to perform the update(s) described in the table above, Renovate ran the
Due to Go's usage of Minimal Version Selection (MVS), these packages have been updated to the minimum version available, so will still abide by Details:
|
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Build break — this bump cannot merge as-is.
pgx 5.11.0 adds TypeMap() to the pgx.Rows interface. The changelog is explicit: "Custom implementations of Rows, including mocks, must add this method."
CatalogRows in flow/shared/postgres.go:99 is a hand-written pgx.Rows wrapper and no longer satisfies the interface, so flow/shared fails to typecheck:
shared/postgres.go:129:10: cannot use CatalogRows{…} (value of struct type CatalogRows) as "github.com/jackc/pgx/v5".Rows value in return statement: CatalogRows does not implement "github.com/jackc/pgx/v5".Rows (missing method TypeMap)
Same error at shared/postgres.go:131, :248 and :250. This is what is failing lint, docker-build and Unit tests (no services) — all three fail on exactly these four lines.
Fix is a one-method passthrough alongside the other CatalogRows wrappers:
func (rows CatalogRows) TypeMap() *pgtype.Map {
return rows.Rows.TypeMap()
}CatalogRows is the only pgx.Rows implementation in the tree, so nothing else needs the same treatment.
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Behaviour change worth flagging (not a blocker): timestamptz text decoding now returns time.Local.
From the pgx 5.11.0 changelog:
timestamptzvalues scanned from the text format are now returned intime.Local, or inScanLocationwhen it is set [...] The instant is unchanged, but everything that renders the location changes with it.
The PG CDC path decodes pgoutput tuples in text format via dt.Codec.DecodeValue(...) (flow/connectors/postgres/cdc.go:470), so every timestamptz coming out of CDC is affected. The replication connection pins timezone=UTC (flow/connectors/postgres/postgres_source.go:85), so time.Parse previously yielded UTC-located values. From 5.11.0 they carry whatever the flow worker time.Local is.
Three places render that location:
flow/model/record_items.go:141—Format("2006-01-02 15:04:05.999999-0700")for the queue and Postgres-destination JSON payloads, so Kafka/PubSub/EventHub consumers would start seeing e.g.+0530instead of+0000.flow/model/qvalue/avro_converter.go:414— the Snowflake string form, same offset change.flow/model/qvalue/avro_converter.go:405-410— the ClickHouse year clamp evaluatest.Year()and rebuilds witht.Location(), so values nearClickHouseMinYear/ClickHouseMaxYearcan clamp differently.
The instant is preserved in all three, and CI runs with TZ: UTC (.github/workflows/flow.yml:47), so this is a no-op for CI and for UTC deployments. It only bites a worker whose local zone is not UTC. To pin it regardless of host TZ, the changelog suggests setting the codec ScanLocation to time.UTC.
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.1 |
There was a problem hiding this comment.
franz-go 1.21.7 → 1.22.1 carries two producer-affecting behaviour changes. Neither breaks the build, but both change runtime behaviour of the Kafka destination.
1. Recreated topics are now a hard failure, and the existing retry does not cover the new error code.
From the 1.22.0 changelog:
The client always produces to and consumes from the first instance of a topic. If you delete and recreate a topic, the client refuses the new version: buffered records fail with
UNKNOWN_TOPIC_ID, fetches stop, offsets from the old topic cannot be committed to the new one, and transactions on the old topic fail.
flow/connectors/kafka/kafka.go:263 only special-cases kerr.UnknownTopicOrPartition (error code 3). UNKNOWN_TOPIC_ID is a distinct code (100), so it falls through to queueErr(err) and fails the sync. This is reachable through the force-topic-creation path here: if a destination topic is dropped and recreated while a kgo.Client is alive (including by the kadm.CreateTopic call at line 267), the client holds the old topic ID and refuses the new instance for the rest of that connector lifetime. Previously franz-go refreshed metadata and carried on. Worth either adding kerr.UnknownTopicID to the handler, or confirming the per-activity connector lifetime makes this self-healing on retry.
2. MaxBufferedRecords default raised 10K → 50K.
The connector never sets MaxBufferedRecords or MaxBufferedBytes, and c.client.Produce(...) at flow/connectors/kafka/kafka.go:289 is called in a tight loop — the franz-go buffer limit is the only backpressure on how many records the flow worker holds in memory per Kafka destination. This bump raises that ceiling 5x. For wide rows that is a material increase in worker RSS. Consider pinning kgo.MaxBufferedRecords(10000) (or a MaxBufferedBytes cap) to keep the previous memory envelope.
The other 1.22.0 breaking changes (ConsumeResetOffset now defaulting to RewindOffset(time.Minute), rack-aware assignment requiring an explicit BalanceRacks(), MaxDecompressBatchBytes becoming fatal on oversized batches) are consumer-side only, and the PeerDB Kafka connector is produce-only, so they do not apply. PoolKRecords is deprecated but unused here.
❌ Test FailureAnalysis: Deterministic compile failure, not a flake: the Renovate pgx/v5 bump added a TypeMap() method to the pgx.Rows interface, which the hand-delegated CatalogRows wrapper in flow/shared/postgres.go does not implement, breaking the build for every Go package. |
96ec351 to
75b946b
Compare
❌ Test FailureAnalysis: Not flaky — a real build break: the Renovate pgx bump added TypeMap() to the pgx.Rows interface, so the hand-written CatalogRows wrapper in flow/shared/postgres.go no longer implements it, failing compilation across all 23 jobs. |
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Blocking — this bump breaks the build.
pgx v5.11.0 adds a TypeMap() method to the pgx.Rows interface. From the release notes: "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."
flow/shared/postgres.go declares CatalogRows as a wrapper struct (named field, not an embedded interface) and spells out every pgx.Rows method by hand, so it no longer satisfies the interface. CI fails at shared/postgres.go lines 129, 131, 248 and 250 with:
cannot use CatalogRows literal (value of struct type CatalogRows) as
github.com/jackc/pgx/v5.Rows value in return statement: CatalogRows does not implementgithub.com/jackc/pgx/v5.Rows (missing method TypeMap)
This is why both docker-build and Unit tests (flow) are red on this PR.
Fix — add the delegate next to the other CatalogRows methods in flow/shared/postgres.go (around line 195, beside Conn()), importing github.com/jackc/pgx/v5/pgtype:
func (rows CatalogRows) TypeMap() *pgtype.Map {
return rows.Rows.TypeMap()
}crdbRows in flow/connectors/cockroachdb/conn.go embeds pgx.Rows, so it picks the new method up automatically and needs no change.
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.1 |
There was a problem hiding this comment.
Non-blocking — two franz-go v1.22.0 behaviour changes land in this range.
-
MaxBufferedRecordsdefault raised 10K → 50K. PeerDB never sets this option —flow/connectors/kafka/kafka.gobuilds its[]kgo.Optwithout it — so every Kafka mirror silently gets a 5x larger producer buffer. Upstream raised it for throughput, but here the buffered items are serialised CDC rows, which can be large. Worth either pinningkgo.MaxBufferedRecords(10_000)to keep the current footprint, or consciously accepting the memory increase. -
Topic recreation is now a hard failure. Upstream: "The client always produces to and consumes from the first instance of a topic. If you delete and recreate a topic, the client refuses the new version: buffered records fail with
UNKNOWN_TOPIC_ID, fetches stop..." PeerDB only matches one error code in its produce callback:// flow/connectors/kafka/kafka.go:263 if errors.Is(err, kerr.UnknownTopicOrPartition) {
So if a destination topic is dropped and recreated while a mirror is running, the callback now sees
UNKNOWN_TOPIC_ID, falls through toqueueErr(err), and the mirror fails instead of self-healing via the force-topic-creation path. Recovery needsPurgeTopicsFromClient. Arguably more correct than the old unreliable behaviour, but thePEERDB_QUEUE_FORCE_TOPIC_CREATIONe2e path is worth a look before merge.
Also in the range and not applicable here, for the record: the ConsumeResetOffset / ConsumeStartOffset decoupling and MaxDecompressBatchBytes only affect consumers (PeerDB is producer-only), and the gzip-to-klauspost switch is moot since no compression option is set.
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Non-blocking, second pgx v5.11.0 note — timestamptz text decoding changes its Location.
Release notes: "timestamptz values scanned from the text format are now returned in time.Local, or in ScanLocation when it is set, matching what the binary format has always returned."
This lands squarely on the CDC path: flow/connectors/postgres/cdc.go:312 decodes replication tuples with pgtype.TextFormatCode, and the resulting time.Time is later rendered with offset-bearing layouts:
flow/model/record_items.go:141—v.Val.Format("2006-01-02 15:04:05.999999-0700"), used for queue destinations (Kafka/PubSub/EventHub) and Elasticsearch JSONflow/model/qvalue/avro_converter.go:426— same layout on the Snowflake string path
The instant is unchanged; the rendered offset is not. On a worker whose TZ is not UTC, CDC rows that previously serialised as ...+0000 (PeerDB forces timezone=UTC on the replication connection, postgres_source.go:85, so the server sent +00) will now serialise with the worker local offset. Default containers are UTC, so most deployments see no change.
Net effect is arguably a fix: the snapshot/QRep path uses the binary format and already produced time.Local, so snapshot and CDC output previously disagreed and now agree. Still, if determinism matters it is cheap to pin it — set ScanLocation: time.UTC on the registered timestamptz codec rather than depending on the worker TZ.
Other items in this range that are relevant and all bug fixes: bounds-checked binary reads across every codec (several panic fixes on malformed records, multiranges and numerics), pgproto3.StartupMessage.Encode now rejects NUL bytes in parameter names/values (an application_name containing an embedded NUL could previously change the role the connection logged in as — PeerDB derives application_name from the flow name at flow/internal/postgres.go:56), and connection-string error redaction now also masks password/sslpassword passed as URI query parameters.
I checked the libpq-compatible URI parser rewrite against GetPGConnectionString (flow/internal/postgres.go:39) and it looks safe: net.JoinHostPort re-adds the IPv6 brackets that SanitizePGHost strips, and the only query params PeerDB sets are application_name, client_encoding and sslmode. The one visible difference is that url.Values.Encode() emits a space as +, which pgx now keeps literal, so a mirror name containing a space would show up as peerdb_my+mirror in pg_stat_activity — cosmetic only.
| github.com/twmb/franz-go/plugin/kslog v1.0.0 | ||
| github.com/twpayne/go-geos v0.22.0 | ||
| github.com/urfave/cli/v3 v3.12.0 | ||
| github.com/twpayne/go-geos v0.23.0 |
There was a problem hiding this comment.
FYI, positive. go-geos v0.23.0 is mostly concurrency fixes that matter here, since PeerDB builds geometries from multiple goroutines:
fix: missing context locking in NewPoint*/NewPolygonfix: NewGeomFromBounds should use mutex and set cleanup(also plugs a C-memory leak)
Plus feat: add Geom.Destroy and re-enabling the GEOS_USE_ONLY_R_API build flag. No API removals. Upstream now tests against GEOS 3.15.0 — worth a sanity check that the libgeos-dev version in the build images and CI is still within the tested range.
|
Dependency-bump review per This PR does not build. No PII/secret-logging concerns — the diff is Three further notes posted inline, none blocking:
Everything else in the range is bug fixes or additive: AWS SDK patches (incl. a transfermanager GetObject reassembly check and an earlier GetObject deadlock fix), grpc v1.84.0 (IDLE-stuck One compatibility item checked and clear: grpc-gateway v2.31.0 raises its minimum Go from 1.25 to 1.26 — |
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Build break — pgx v5.11.0 adds TypeMap() to the pgx.Rows interface.
From the v5.11.0 release notes: Add Rows.TypeMap to expose the type map used to decode rows [...] Custom implementations of Rows, including mocks, must add this method.
shared.CatalogRows (flow/shared/postgres.go:99) holds pgx.Rows as a named field rather than an embedded one, and forwards each interface method by hand (Close, Err, CommandTag, FieldDescriptions, Next, Scan, Values, RawValues, Conn). So it does not pick up the new method and no longer satisfies pgx.Rows.
This is already red on this PR — lint, Unit tests (no services) and docker-build all fail with:
shared/postgres.go:129:10: cannot use CatalogRows ... as pgx.Rows value in return
statement: CatalogRows does not implement pgx.Rows (missing method TypeMap)
shared/postgres.go:131:9, 248:10, 250:9: same
Fix is one forwarder alongside the others in flow/shared/postgres.go (pgtype is already imported there at line 14):
func (rows CatalogRows) TypeMap() *pgtype.Map {
return rows.Rows.TypeMap()
}CatalogRows is the only hand-rolled pgx.Rows in the tree — conncockroachdb.crdbRows (flow/connectors/cockroachdb/conn.go:65) embeds pgx.Rows, so it inherits TypeMap() for free and needs no change.
| github.com/ClickHouse/clickhouse-go/v2 v2.48.0 | ||
| github.com/go-mysql-org/go-mysql v1.15.0 | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Behavior change worth a conscious decision (same pgx bump): text-format timestamptz is now returned in time.Local.
From the v5.11.0 notes: timestamptz values scanned from the text format are now returned in time.Local, or in ScanLocation when it is set, matching what the binary format has always returned. Previously the text path kept whatever location time.Parse derived from the offset the server sent.
This lands squarely on the Postgres CDC path. pgoutput delivers tuple values in text format, and flow/connectors/postgres/cdc.go:470 decodes them via dt.Codec.DecodeValue(p.typeMap, dataType, formatCode, data) — exactly the path whose location semantics changed.
The instant is unchanged, but two places render the location, and they will emit different literals for sources whose session TimeZone is not UTC:
flow/model/record_items.go:141— formats with layout2006-01-02 15:04:05.999999-0700, which feeds the JSON payload for the queue destinations (Kafka / PubSub / Elasticsearch).flow/model/qvalue/avro_converter.go:414and:426— the Snowflake Avro string form uses the same offset-bearing layout.
A row the server sent as ...+05:30 previously serialized with +0530; it will now serialize with the flow worker local offset (UTC in the shipped containers). Consumers that parse the offset see the same instant, so this is not data loss — but it is a visible change in delivered payloads arriving via a bump that looks routine. If the old rendering matters, set ScanLocation on the timestamptz codec in the CDC type map to pin it.
Two related items from the same release that PeerDB happens to be safe on: pgx.RowToStructByName now matches db tags case-insensitively (this repo only uses RowToStructByPos), and the new Config.MaxProtocolMessageBodyLen defaults to 0 = unlimited, so large rows are not newly capped.
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.1 |
There was a problem hiding this comment.
franz-go v1.22.0 raises the default MaxBufferedRecords from 10K to 50K — 5x the Kafka sink memory ceiling.
From the v1.22.1 changelog: MaxBufferedRecords now has a default of 50K, up from 10K.
NewKafkaConnector (flow/connectors/kafka/kafka.go:72-77) builds its option list without kgo.MaxBufferedRecords or kgo.MaxBufferedBytes — it only sets kgo.ProducerBatchMaxBytes, and only when config.MaxRecordBatchBytes is present. Since c.client.Produce(...) (kafka.go:280 and :289) blocks once the buffered-record limit is reached, that default is the only backpressure between the CDC/QRep record stream and the producer, and it is counted in records with no byte bound at all.
So after this bump a Kafka mirror can hold 50K unflushed records in the flow worker instead of 10K. For wide CDC rows that is a real step up in peak RSS inside a memory-capped container, and it arrives silently with a bump that reads as routine.
Suggest pinning the prior behavior explicitly rather than inheriting the new default — e.g. adding kgo.MaxBufferedRecords(10_000) to optionalOpts, and/or kgo.MaxBufferedBytes if bounding by size is preferable to bounding by count.
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.1 | ||
| github.com/twmb/franz-go/pkg/kadm v1.19.0 |
There was a problem hiding this comment.
franz-go v1.22.0 makes topic recreation fatal with UNKNOWN_TOPIC_ID, which the Kafka produce handler does not recognise.
(Filed on the kadm line because kadm is what the affected code path calls, but it is the franz-go v1.22.0 change on the line above that causes it.)
From the v1.22.0 changelog: Topic recreation is now a hard failure. [...] If you delete and recreate a topic, the client refuses the new version: buffered records fail with UNKNOWN_TOPIC_ID, fetches stop [...] Previously, some things in the client continued to accidentally work.
The produce error handler at flow/connectors/kafka/kafka.go:260-287 special-cases exactly one error:
if errors.Is(err, kerr.UnknownTopicOrPartition) {
// PeerDBQueueForceTopicCreation -> kadm.NewClient(c.client).CreateTopic(...) -> retry Produce
} else {
c.logger.Warn(...)
}
...
queueErr(err) // fails the synckerr.UnknownTopicID is a distinct error from kerr.UnknownTopicOrPartition, so a recreated destination topic now falls into the else branch and aborts the sync via queueErr instead of reaching the force-create-and-retry path. The connector is rebuilt per sync activity, so a retried sync gets a fresh kgo.Client and recovers — but the in-flight batch fails where it previously had a chance to self-heal, and the PeerDBQueueForceTopicCreation escape hatch no longer covers this case.
Worth widening the condition to errors.Is(err, kerr.UnknownTopicOrPartition) || errors.Is(err, kerr.UnknownTopicID). Note that recovering a genuinely recreated topic also needs PurgeTopicsFromClient per the upstream notes — CreateTopic alone will not clear the pinned topic ID held by the client.
Two other v1.22.0 behavior changes I checked and believe are inert here: the new MaxDecompressBatchBytes 1GiB bound is consume-side only (this connector is produce-only), and the ConsumeResetOffset default change to RewindOffset(time.Minute) does not apply since no kgo consumer options are set. gzip now routing through klauspost/compress changes the exact bytes a given WithLevel(n) emits, but PeerDB never configures producer compression.
|
Dependency-bump review (per Read the upstream release notes / commit logs for every bumped range and cross-checked them against how PeerDB actually uses each library. 4 findings posted as inline comments, including one hard compile break that this PR CI has already confirmed:
Reviewed and clean
Secret/PII check (REVIEW.md item 1) Nothing introduced — the diff is manifests only. The pgx bump actually improves this: v5.11.0 now redacts I could not run |
❌ Test FailureAnalysis: The Renovate pgx/v5 bump added a TypeMap() method to the pgx.Rows interface, which the hand-written CatalogRows wrapper in flow/shared/postgres.go does not implement, breaking the build for every flow package and failing all jobs deterministically. |
a41e8a2 to
f20d035
Compare
❌ Test FailureAnalysis: Not flaky — the Renovate pgx/v5 bump added a TypeMap() method to the pgx.Rows interface, so the CatalogRows wrapper in flow/shared/postgres.go no longer implements it, causing a deterministic build failure that blocked every unit-test package and all 20 tilt matrix jobs before any test ran. |
| github.com/grpc-ecosystem/grpc-gateway/v2 v2.31.0 | ||
| github.com/hamba/avro/v2 v2.31.0 | ||
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce |
There was a problem hiding this comment.
pgx 5.11.0 adds a method to the pgx.Rows interface — this looks like a compile break.
From the 5.11.0 changelog:
Add
Rows.TypeMapto expose the type map used to decode rows, including rows created byRowsFromResultReaderthat have no underlyingConn. Custom implementations ofRows, including mocks, must add this method.
Confirmed against rows.go at v5.11.0 — the interface now declares TypeMap() *pgtype.Map.
shared.CatalogRows is a custom implementation that wraps pgx.Rows in a named field rather than embedding it, so it gets no method promotion (flow/shared/postgres.go:99-101). It hand-forwards exactly nine methods — Close, Err, CommandTag, FieldDescriptions, Next, Scan, Values, RawValues, Conn — and has no TypeMap. After this bump it no longer satisfies pgx.Rows, so both returns in CatalogPool.Query (flow/shared/postgres.go:129, :131) and both in CatalogTx.Query (:248, :250) fail to compile.
By contrast crdbRows (flow/connectors/cockroachdb/conn.go:65-67) embeds pgx.Rows, so it picks the new method up for free. Only CatalogRows needs a forwarder: a TypeMap() *pgtype.Map method on CatalogRows returning rows.Rows.TypeMap().
| @@ -66,11 +66,11 @@ require ( | |||
| github.com/snowflakedb/gosnowflake/v2 v2.2.0 | |||
| github.com/stretchr/testify v1.12.1 | |||
| github.com/testcontainers/testcontainers-go v0.44.0 | |||
There was a problem hiding this comment.
franz-go 1.22.1 raises the MaxBufferedRecords default from 10K to 50K — the Kafka destination never sets it explicitly.
From the 1.22.1 changelog:
MaxBufferedRecordsnow has a default of 50K, up from 10K: 10K was chosen when I initially wrote this library and is a very low default limit for average sized records.
KafkaConnector.Connect (flow/connectors/kafka/kafka.go:73-140) builds its option slice with SeedBrokers, AllowAutoTopicCreation, WithLogger, plus optional ProducerBatchMaxBytes / partitioner / SASL / TLS — but never kgo.MaxBufferedRecords. Since SyncRecords produces in a tight loop (c.client.Produce(ctx, kr, handler) at kafka.go:289) and relies on Produce blocking once the buffer fills as its only backpressure, this bump raises the producer in-memory ceiling ~5x per mirror. With MaxBufferedBytes also unset, record count is the sole bound: a mirror replicating 10 KB rows goes from roughly 100 MB to 500 MB of buffered records, multiplied by every concurrent Kafka mirror in the worker.
Worth pinning kgo.MaxBufferedRecords(10_000) (or a PEERDB_-tunable value) alongside the existing ProducerBatchMaxBytes option so worker memory does not silently grow on upgrade.
| github.com/jackc/pgerrcode v0.0.0-20250907135507-afb5586c32a6 | ||
| github.com/jackc/pglogrepl v0.0.0-20260824121319-4ae5c490f7ce | ||
| github.com/jackc/pgx/v5 v5.10.0 | ||
| github.com/jackc/pgx/v5 v5.11.0 |
There was a problem hiding this comment.
Blocking — this bump breaks the build.
pgx v5.11.0 adds TypeMap() *pgtype.Map to the pgx.Rows interface: "Custom implementations of Rows, including mocks, must add this method" (release notes). shared.CatalogRows in flow/shared/postgres.go delegates every pgx.Rows method by hand instead of embedding, so it no longer satisfies the interface:
shared/postgres.go:129:10: cannot use CatalogRows{…} (value of struct type CatalogRows) as "github.com/jackc/pgx/v5".Rows value in return statement: CatalogRows does not implement "github.com/jackc/pgx/v5".Rows (missing method TypeMap)
shared/postgres.go:131:9: ... (same)
shared/postgres.go:248:10: ... (same)
shared/postgres.go:250:9: ... (same)
That is what docker-build (ubuntu-latest) and Unit tests (no services) are failing on.
Fix — add next to the other delegating methods in flow/shared/postgres.go (pgtype is already imported there):
func (rows CatalogRows) TypeMap() *pgtype.Map {
return rows.Rows.TypeMap()
}crdbRows in flow/connectors/cockroachdb/conn.go embeds pgx.Rows, so it picks the new method up for free — CatalogRows is the only hand-rolled implementation in the repo.
Also worth a look before merging — v5.11.0 rewrote the pgtype date/time text parser, and two of the resulting behavior changes touch replication paths:
datenow rejects impossible dates instead of normalizing them.2024-02-30used to scan as2024-03-01and2024-13-01as2025-01-01; both are errors now. Source rows with odd/corrupt dates that previously replicated silently will fail the batch instead.timestamptzscanned over the text format is now returned intime.Local(or the codecScanLocation) rather than the offset the server sent, soLocation(),Zone()andTimestamptz.MarshalJSONrender differently (the instant is unchanged). The QRep/initial-load path uses the default binary exec mode and is unaffected, butconnectors/postgres/postgres_source.go:95,connectors/postgres/client.go:266,279and several e2e suites runpgx.QueryExecModeSimpleProtocol, which yields text results.
One upside: v5.11.0 widens pgconn connection-string redaction in error messages to URI query params (?password=, ?sslpassword=), not just userinfo — one less way a credential reaches PeerDB logs.
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 |
There was a problem hiding this comment.
franz-go v1.21.7 → v1.22.2 introduces a produce error code the Kafka connector doesn't handle.
v1.22 added topic-recreation detection (35efafc). When kgo sees a topic name remapped to a new topic ID, it now abandons that topic's record buffers the way a purge does: everything buffered — and everything buffered afterwards — fails with kerr.UnknownTopicID (code 100) "until the topic is purged and produced to again". Previously, at produce versions below v13 the request carried the topic name and the new topic simply answered it, so the records silently went through. The commit message calls out that Redpanda caps produce at v7, so every Redpanda producer was in that silent-success case — and Redpanda is a supported destination here.
The produce handler in flow/connectors/kafka/kafka.go:260-287 only special-cases kerr.UnknownTopicOrPartition (code 3) for its force-topic-creation recovery. kerr.UnknownTopicID is a distinct *kerr.Error, so errors.Is won't match it and it falls into the else branch → queueErr(err) → the sync batch fails.
This needs an external drop-and-recreate of the destination topic during a mirror to trigger, so it isn't common, and it should self-heal on activity retry (a new KafkaConnector gets a fresh kgo.Client with no stale topic ID). Worth knowing about if Kafka/Redpanda mirrors start surfacing UNKNOWN_TOPIC_ID errors after this merges. If you do want to handle it in-process, note that per the commit the client stays poisoned for that topic until PurgeTopicsFromClient + a re-produce — a plain retry on the same client won't clear it.
| cloud.google.com/go/bigquery v1.74.0 | ||
| cloud.google.com/go/pubsub/v2 v2.3.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.2.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.3.0 |
There was a problem hiding this comment.
This module gets the gosnowflake v2.3.0 OCSP default change but not the OCSPFailOpen fix.
flow/connectors/snowflake/snowflake.go was updated in this PR to set OCSPFailOpen: gosnowflake.OCSPFailOpenTrue, because v2.3.0 turns OCSP certificate revocation checking off by default (FillMissingConfigParameters no longer defaults OCSPFailOpen, and transportFactory.createTransport now gates on sfconfig.OCSPEnabled(cfg) instead of !DisableOCSPChecks).
e2e_cleanup/main.go:183-196 builds its own gosnowflake.Config and doesn't set it, so after this bump that binary connects to Snowflake with revocation checking fully disabled — OcspMode reports INSECURE.
It's a CI cleanup utility rather than a production path, so this is low severity, but it does authenticate with a real JWT private key and it's now silently inconsistent with the connector. Either mirror the one-line OCSPFailOpen: gosnowflake.OCSPFailOpenTrue into that config, or leave a comment there saying the omission is deliberate so the next reader doesn't have to re-derive it.
| cloud.google.com/go/bigquery v1.74.0 | ||
| cloud.google.com/go/auth v0.24.1 | ||
| cloud.google.com/go/bigquery v1.85.0 | ||
| cloud.google.com/go/cloudsqlconn v1.22.1 |
There was a problem hiding this comment.
The PR description lists four updates that aren't actually in this diff. Checked against the files at HEAD — all four are unchanged from the base commit (4dbe4f5):
| Listed in the body | Actual state |
|---|---|
cloud.google.com/go/cloudsqlconn v1.22.1 → v1.25.4 |
still v1.22.1 (this line) |
github.com/jackc/pgx/v5 v5.10.0 → v5.11.0 |
still v5.10.0 in both flow/go.mod and flow/pkg/go.mod |
github.com/pressly/goose/v3 v3.28.0 → v3.29.0 |
still v3.28.0 |
github.com/shopspring/decimal v1.4.0 → v1.5.0 |
still v1.4.0 |
Two reasons this is worth correcting rather than ignoring:
- The cloudsqlconn v1.25.4 section is the only place in the body that advertises the
golang.org/x/netHTTP/2 CVE fixes (GO-2026-6603 / 6610 / 6611 / 6612 / 6617). Those fixes do land in this PR — but via thegolang.org/x/net v0.59.0 → v0.61.0indirect bump, not via cloudsqlconn, which didn't move. Easy to read the body and draw the wrong conclusion about what's providing them. pgx/v5andshopspring/decimalsit on hot paths (PG replication, numeric conversion), anddecimalv1.4 → v1.5 in particular isn't one you'd want waved through on the assumption it was already reviewed here. A reviewer working down the table would spend effort on four packages that aren't in the change set, and Renovate will presumably re-propose them.
Not a blocker for the dependency changes that are here — flagging so the description doesn't get taken at face value.
(Related but benign: golang.org/x/oauth2 is listed as a v0.36.0 → v0.37.0 direct require, but in the diff it moves out of the direct block into // indirect. That one is correct — no Go file under flow/ imports golang.org/x/oauth2, so go mod tidy demoting it is right.)
❌ Test FailureAnalysis: Not flaky — a deterministic clickhouse-go protocol incompatibility with clickhouse-server:latest ("unsupported column type "contact.phone.cell"" when decoding JSON columns, followed by connection desync) failed every ch-latest job that runs the ClickHouse JSON suite while all ch-lts/ch-stable jobs and ch-latest jobs that skip that suite passed. |
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 |
There was a problem hiding this comment.
franz-go v1.22.1 raises the MaxBufferedRecords default from 10K to 50K — this repo never sets it, so the Kafka connector memory ceiling silently goes up 5x.
From the v1.22.1 changelog:
MaxBufferedRecordsnow has a default of 50K, up from 10K: 10K was chosen when I initially wrote this library and is a very low default limit for average sized records.
This is not just a tuning knob — it is the producer backpressure mechanism. Upstream config.go:
Sets the max amount of records the client will buffer, blocking produces until records are finished if this limit is reached. This overrides the default of 50,000.
NewKafkaConnector (flow/connectors/kafka/kafka.go:72-140) builds its []kgo.Opt without kgo.MaxBufferedRecords(...), and SyncRecords fans out via c.client.Produce(ctx, kr, handler) in a loop with no other bound on in-flight records. So after this bump each Kafka mirror can hold 50K un-acked CDC records in memory before Produce blocks, instead of 10K.
For a CDC pipeline where a single record can be a wide row, and where a deployment runs many concurrent mirrors, that is a real change in peak RSS per worker rather than a cosmetic default. If the previous 10K was load-bearing for memory behaviour, consider pinning it explicitly:
kgo.MaxBufferedRecords(10_000),
or deliberately adopting 50K after checking worker memory limits. Either way it is better as a conscious choice than an inherited default change.
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 | ||
| github.com/twmb/franz-go/pkg/kadm v1.19.0 |
There was a problem hiding this comment.
franz-go v1.22.0 makes topic recreation a hard failure, which interacts with the force-topic-creation retry path in flow/connectors/kafka/kafka.go.
From the v1.22.0 changelog:
Topic recreation is now a hard failure. The client always produces to and consumes from the first instance of a topic.
Once a topic is deleted and recreated, the client refuses the new instance: buffered records fail with UNKNOWN_TOPIC_ID and keep failing until the application calls PurgeTopicsFromClient. Previously "some things in the client continued to accidentally work".
The relevant path is the produce-error handler at flow/connectors/kafka/kafka.go:260-287, which on kerr.UnknownTopicOrPartition calls kadm.NewClient(c.client).CreateTopic(...) and then re-produces on the same c.client. If the topic previously existed within that client lifetime and was dropped (the force-topic-creation flow, or a user dropping the destination topic mid-sync), the recreated topic now has a new topic ID that this client will permanently reject — so the retry at line 280 fails with UNKNOWN_TOPIC_ID rather than succeeding, and no amount of retrying recovers it.
Exposure is limited by the connector (and therefore the kgo.Client) being relatively short-lived, so this is narrower than the buffering change on the line above — but recreate-then-retry-on-the-same-client is exactly the shape the upstream note calls out. Adding a PurgeTopicsFromClient(kr.Topic) before the retry would make that path robust under the new semantics.
| go.opentelemetry.io/otel/sdk/metric v1.47.0 | ||
| go.opentelemetry.io/otel/trace v1.47.0 | ||
| go.temporal.io/api v1.63.7 | ||
| go.temporal.io/sdk v1.50.0 |
There was a problem hiding this comment.
Note (log volume, not correctness): Temporal SDK v1.50.0 changes the [TMPRL1104] workflow-task-duration logging:
The
[TMPRL1104]workflow task duration log now uses a single warning threshold, configurable with theTEMPORAL_WORKFLOW_TASK_DURATION_WARN_SECONDSenvironment variable and defaulting to 5 seconds. It previously warned above a fixed 10 seconds, logged at info above a fixed 5 seconds, and logged at debug below that when trace logging was enabled.
Workflow tasks in the 5-10s band that used to log at INFO will now log at WARN. Given how long PeerDB workflow tasks can run, expect a step up in WARN-level noise after this bump, and any alerting keyed on worker WARN logs may get louder. Setting TEMPORAL_WORKFLOW_TASK_DURATION_WARN_SECONDS=10 restores the old warning threshold if that turns out to be noisy.
The other v1.50.0 breaking changes (the contrib/googleadk module move, the plugin-cleanup deadlock, the PurgeStickyWorkflowCache eviction-metric change, and the removal of MaxConcurrentWorkflowTaskExternalStorageVisits) do not apply — none of those symbols appear anywhere in this repo.
| github.com/google/uuid v1.6.0 | ||
| github.com/grpc-ecosystem/go-grpc-middleware/v2 v2.3.4 | ||
| github.com/grpc-ecosystem/grpc-gateway/v2 v2.30.0 | ||
| github.com/grpc-ecosystem/grpc-gateway/v2 v2.32.0 |
There was a problem hiding this comment.
Note (worth a sanity check on the REST API): grpc-gateway v2.32.0 includes two changes to how ServeMux decodes path parameters:
stop double-unescaping path params in ServeMux.ServeHTTP(#7449)treat %2f as a path separator in encodedPathSplitter(#7486)
protos/route.proto routes a lot of user-controlled names through single-segment path params — /v1/peers/info/{peer_name}, /v1/peers/slots/{peer_name}, /v1/mirrors/cdc/batches/{flow_job_name}, /v1/flows/tags/{flow_name}, /v1/scripts/{id}. A peer or mirror name containing % or an encoded / will decode differently after this bump: previously-double-unescaped values now arrive singly-unescaped, and a %2F in a name now splits the path instead of being absorbed into the parameter (likely a 404 rather than a lookup by that name).
This only bites if such names are reachable in practice, which depends on PeerDB name validation, so flagging it for confirmation rather than asserting breakage. Also in this range: reject duplicate fields in DefaultQueryParser.Parse (v2.32.0), which turns a previously-tolerated duplicate query parameter into an error for any API client that sends one.
|
Renovate bump review — upstream release notes checked Reviewed per Verified correct
I specifically checked the non-obvious risk: this code builds a and Security fixes picked up by this bump, all good reasons to merge:
Breaking changes checked and confirmed not to affect this repo:
Findings (inline)
One process note The branch carries a commit "Keep clickhouse-go at v2.48.0 to isolate JSON CI failures", and |
❌ Test FailureAnalysis: Not flaky and not caused by this Renovate PR: all three major failures are ClickHouse JSON-type breakage confined to the floating clickhouse/clickhouse-server:latest image (every ch-stable/ch-lts job passed the same JSON tests, and the ch-latest jobs that passed all skip them), with one genuinely flaky timing failure in TestSSHKeepaliveTunnelDown on mysql-gtid_ch-lts. |
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 |
There was a problem hiding this comment.
franz-go v1.22.0 raises the MaxBufferedRecords default from 10K to 50K.
The Kafka connector never sets kgo.MaxBufferedRecords (see the option list in flow/connectors/kafka/kafka.go:72-133), so it inherits the new default. SyncRecords relies on client.Produce blocking at that limit for backpressure, so up to 5x more CDC records — each an already-serialized payload — can now sit in the producer buffer per mirror before producing blocks. With several Kafka mirrors per flow worker that is a real resident-memory increase.
Upstream rationale: "10K was chosen when I initially wrote this library and is a very low default limit for average sized records. The librdkafka default is 100K; 50K increases producer throughput while still keeping producer memory low."
Consider pinning kgo.MaxBufferedRecords(10_000) (or making it env-tunable) to preserve the previous memory profile, rather than inheriting the change silently.
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 | ||
| github.com/twmb/franz-go/pkg/kadm v1.19.0 |
There was a problem hiding this comment.
franz-go v1.22.0 turns topic recreation into a hard failure, and the resulting error does not reach the force-topic-creation recovery path.
From the v1.22.0 changelog: "The client always produces to and consumes from the first instance of a topic. If you delete and recreate a topic, the client refuses the new version: buffered records fail with UNKNOWN_TOPIC_ID, fetches stop, offsets from the old topic cannot be committed to the new one, and transactions on the old topic fail."
The produce handler in createPool (flow/connectors/kafka/kafka.go:260-287) only special-cases kerr.UnknownTopicOrPartition; every other error falls through to queueErr(err). So if a destination topic is dropped and recreated while a mirror is running, records now fail permanently with kerr.UnknownTopicID and the mirror errors out, where previously the client would have followed the new topic.
Two things worth doing: handle kerr.UnknownTopicID alongside kerr.UnknownTopicOrPartition, and confirm PEERDB_QUEUE_FORCE_TOPIC_CREATION still works under v1.22 — that path creates the topic via kadm and re-produces a record for a topic the client has already resolved as missing, which is adjacent to the new first-instance tracking.
| cloud.google.com/go/bigquery v1.74.0 | ||
| cloud.google.com/go/pubsub/v2 v2.3.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.2.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.3.0 |
There was a problem hiding this comment.
This module gets the same gosnowflake v2.3.0 bump that turns OCSP revocation checking off by default, but unlike flow/connectors/snowflake/snowflake.go it was not given the OCSPFailOpen opt-in — e2e_cleanup/main.go:183 builds its gosnowflake.Config without it, so this utility silently drops certificate revocation checking.
Low impact since it is internal test tooling rather than a shipped code path, but worth keeping consistent with the connector fix.
🔄 Flaky Test DetectedAnalysis: TestCockroachDBSuite/Test_CDC_Live_PullRecords got 3 of 6 expected CDC records because the connector's batch deadline (first record + 5s IdleTimeout, closed on the next resolved timestamp) cut the single non-retrying pull short — a timing race, corroborated by the other CockroachDB matrix jobs passing on the same commit and the failing PR being only a gomod version bump. ✅ Automatically retrying the workflow |
This reverts commit da7a31c.
| github.com/testcontainers/testcontainers-go v0.44.0 | ||
| github.com/twmb/franz-go v1.21.7 | ||
| github.com/twmb/franz-go/pkg/kadm v1.18.0 | ||
| github.com/twmb/franz-go v1.22.2 |
There was a problem hiding this comment.
franz-go v1.22.0 raises the MaxBufferedRecords default from 10,000 to 50,000 — a 5x increase in the worst-case in-memory producer buffer.
From the v1.22.0 changelog:
MaxBufferedRecordsnow has a default of 50K, up from 10K [...] The librdkafka default is 100K; 50K increases producer throughput while still keeping producer memory low.
Confirmed in pkg/kgo/config.go at v1.22.2: maxBufferedRecords: 50000.
This lands on us because NewKafkaConnector (flow/connectors/kafka/kafka.go:72-140) sets neither kgo.MaxBufferedRecords nor kgo.MaxBufferedBytes — the only sizing option we pass is kgo.ProducerBatchMaxBytes, which bounds a batch, not the buffer. So record count is currently the only backpressure bound, and c.client.Produce(ctx, kr, handler) blocking on that limit is what keeps the Lua pool from running ahead.
The upstream rationale (still keeping producer memory low) assumes average-sized records. PeerDB buffers whole CDC rows post-Lua, often JSON, so per-record size can be orders of magnitude larger, and this multiplies peak heap per Kafka connector by 5x. With PeerDBQueueParallelism workers feeding a single client, that is a plausible OOM regression on wide-table mirrors.
Worth making the bound explicit rather than inheriting whichever default upstream picks each release: kgo.MaxBufferedRecords(10_000) to hold current behaviour, or better kgo.MaxBufferedBytes(...) so the limit tracks actual memory instead of record count.
| cloud.google.com/go/bigquery v1.74.0 | ||
| cloud.google.com/go/pubsub/v2 v2.3.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.2.0 | ||
| github.com/snowflakedb/gosnowflake/v2 v2.3.0 |
There was a problem hiding this comment.
This module gets the same gosnowflake/v2 v2.3.0 bump that turns OCSP revocation checking off by default, but unlike flow/connectors/snowflake/snowflake.go the gosnowflake.Config at e2e_cleanup/main.go:183-197 was not given a matching OCSPFailOpen: gosnowflake.OCSPFailOpenTrue.
Net effect: Snowflake connections from this tool silently lose certificate revocation checking after the bump. It is a CI cleanup utility rather than a production path, so low severity — but it is exactly the behaviour change the connector-side change was written to compensate for, and leaving the two modules divergent means whoever revisits the // TODO: when upstream defaulting CRL checking to on, switch to that note in snowflake.go will not find this call site.
🔄 Flaky Test DetectedAnalysis: Two BigQuery e2e matrix legs timed out on different, unrelated tests (GCS object-listing wait and a STATUS_SNAPSHOT wait) against live Google Cloud while the third leg passed the identical 59-test selection, indicating timing/race flakiness rather than a regression from this gomod bump. ✅ Automatically retrying the workflow |
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
v1.22.1→v1.25.4v0.9.0→v0.10.0v1.33.0→v1.35.0v1.36.0v1.14.1→v1.15.0v2.48.0→v2.49.0v0.57.17→v0.58.17v2.12.0→v2.13.0v1.47.0→v1.47.3v1.47.4v1.33.5→v1.33.9v1.33.10v1.20.5→v1.20.9v1.20.10v1.7.3→v1.7.6v1.7.7v0.4.7→v0.4.16v0.4.19(+2)v1.60.0→v1.61.4v1.61.6(+1)v1.113.1→v1.114.3v1.114.5(+1)v1.42.0→v1.42.4v1.42.5v1.51.0→v1.51.4v1.51.5v1.28.1→v1.28.5v1.28.6v2.30.0→v2.32.0v5.10.0→v5.11.0v1.56.0→v1.56.1v3.28.0→v3.29.0v1.4.0→v1.5.0v1.6.0v0.29.0→v0.30.1v2.2.0→v2.3.0v1.21.7→v1.22.2v1.18.0→v1.19.0v0.22.0→v0.23.0v3.12.0→v3.14.0v2.9.1→v2.9.2v0.71.0→v0.72.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.46.0→v1.47.0v1.63.5→v1.63.7v1.64.0v1.49.0→v1.50.0v0.57.0→v0.58.085c1c22→f0251ebv0.36.0→v0.37.0v0.23.0→v0.24.0v0.42.0→v0.43.0v0.50.0→v0.52.0v1.83.2→v1.84.0v0.37.0→v0.37.1Release Notes
googlecloudplatform/cloud-sql-go-connector (cloud.google.com/go/cloudsqlconn)
v1.25.4Compare Source
Bug Fixes
Security / CVE Fixes
Updates
golang.org/x/netfromv0.59.0tov0.61.0, resolving the following HTTP/2 vulnerabilities:golang.org/x/netv0.61.0golang.org/x/netv0.61.0golang.org/x/netv0.61.0golang.org/x/netv0.61.0golang.org/x/netv0.61.0v1.25.3Compare Source
Bug Fixes
v1.25.2Compare Source
Bug Fixes
v1.25.1Compare Source
Bug Fixes
v1.25.0Compare Source
Features
Bug Fixes
v1.24.0Compare Source
Features
Bug Fixes
v1.23.0Compare Source
Features
Bug Fixes
googleapis/google-cloud-go (cloud.google.com/go/compute/metadata)
v0.10.0pubsub: Subscription.ModifyPushConfig replaced with Subscription.Update.
pubsub: Subscription.Receive now runs concurrently for higher throughput.
vision: cloud.google.com/go/vision is deprecated. Use
cloud.google.com/go/vision/apiv1 instead.
translation: now stable.
trace: several changes to the surface. See the link below.
Code changes required from v0.9.0
pubsub: Replace
with
trace: traceGRPCServerInterceptor will be provided from *trace.Client.
Given an initialized
*trace.Clientnamedtc, instead ofwrite
trace trace.GRPCClientInterceptor will also provided from *trace.Client.
Instead of
write
trace: We removed the deprecated
trace.EnableGRPCTracing. Use the gRPCinterceptor as a dial option as shown below when initializing Cloud package
clients:
v0.9.1: compute/metadata: v0.9.1Bug Fixes
Azure/azure-sdk-for-go (github.com/Azure/azure-sdk-for-go/sdk/azidentity)
v1.15.01.15.0 (2026-10-14)
Features Added
ManagedIdentityCredentialandDefaultAzureCredentialsupport user-assigned managed identitieson Azure Arc when the agent supports them
WorkloadIdentityCredentialsupports identity binding mode viaWorkloadIdentityCredentialOptions.EnableAzureProxyBugs Fixed
ManagedIdentityCredentialverifies the Service Fabric endpoint's certificate againstIDENTITY_SERVER_THUMBPRINTand rejects redirectsOther Changes
ClientOptions.Transportmust be an*http.Clientwith anilTransport or a standard
*http.Transportwithout custom TLS dialing or verification callbacks.Unsupported transports now cause credential construction to fail
ClickHouse/clickhouse-go (github.com/ClickHouse/clickhouse-go/v2)
v2.49.0Compare Source
What's Changed
Improvements 🚀
fmt.Stringerin server-side query parameter switch by @adamgonen in #2002Bug fixes 🐛
Other Changes 🛠
New Contributors
Full Changelog: ClickHouse/clickhouse-go@v2.48.0...v2.49.0
PeerDB-io/crypto (github.com/PeerDB-io/crypto)
v0.58.17Compare Source
Shopify/toxiproxy (github.com/Shopify/toxiproxy/v2)
v2.13.0average_size<= 0 orsize_variationoutside[0, average_size],and stop the slicer from recursing forever on degenerate sizes (#774, @iyaz-shaikh)
TOXIPROXY_AUTH_TOKEN, supported by the Goclient and
toxiproxy-cli, and warn when the API is unauthenticated on a non-loopback address(#774, @iyaz-shaikh)
toxic or connection is already gone (#760, @matheusgb)
rate<= 0 (#764, @jaideeppyne)aws/aws-sdk-go-v2 (github.com/aws/aws-sdk-go-v2)
v1.47.3Compare Source
Module Highlights
github.com/aws/aws-sdk-go-v2/service/acmpca: v1.37.3github.com/aws/aws-sdk-go-v2/service/databasemigrationservice: v1.43.0github.com/aws/aws-sdk-go-v2/service/ec2: v1.182.0github.com/aws/aws-sdk-go-v2/service/ecs: v1.47.3github.com/aws/aws-sdk-go-v2/service/elasticinference: v1.23.3github.com/aws/aws-sdk-go-v2/service/iotfleetwise: v1.20.0github.com/aws/aws-sdk-go-v2/service/neptunegraph: v1.14.0github.com/aws/aws-sdk-go-v2/service/outposts: v1.45.0github.com/aws/aws-sdk-go-v2/service/route53resolver: v1.33.0github.com/aws/aws-sdk-go-v2/service/socialmessaging: v1.0.0v1.47.2Compare Source
Module Highlights
github.com/aws/aws-sdk-go-v2/service/customerprofiles: v1.49.0github.com/aws/aws-sdk-go-v2/service/ec2: v1.239.0github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2: v1.47.2github.com/aws/aws-sdk-go-v2/service/entityresolution: v1.21.0github.com/aws/aws-sdk-go-v2/service/glue: v1.121.0github.com/aws/aws-sdk-go-v2/service/inspector2: v1.40.0github.com/aws/aws-sdk-go-v2/service/iot: v1.66.0github.com/aws/aws-sdk-go-v2/service/opensearch: v1.49.0github.com/aws/aws-sdk-go-v2/service/quicksight: v1.90.0github.com/aws/aws-sdk-go-v2/service/s3control: v1.62.0github.com/aws/aws-sdk-go-v2/service/sesv2: v1.49.0github.com/aws/aws-sdk-go-v2/service/workspacesweb: v1.29.0v1.47.1Compare Source
Module Highlights
github.com/aws/aws-sdk-go-v2/service/bedrockagentcore: v1.49.0github.com/aws/aws-sdk-go-v2/service/connect: v1.200.0github.com/aws/aws-sdk-go-v2/service/ec2: v1.334.0github.com/aws/aws-sdk-go-v2/service/guardduty: v1.93.0github.com/aws/aws-sdk-go-v2/service/iotwireless: v1.65.0github.com/aws/aws-sdk-go-v2/service/notifications: v1.17.0github.com/aws/aws-sdk-go-v2/service/sesv2: v1.74.0github.com/aws/aws-sdk-go-v2/service/sns: v1.47.1github.com/aws/aws-sdk-go-v2/service/socialmessaging: v1.21.0github.com/aws/aws-sdk-go-v2/service/vpclattice: v1.33.0aws/smithy-go (github.com/aws/smithy-go)
v1.28.5Compare Source
General Highlights
Module Highlights
github.com/aws/smithy-go: v1.28.5v1.28.4Compare Source
General Highlights
Module Highlights
github.com/aws/smithy-go: v1.28.4v1.28.3Compare Source
General Highlights
Module Highlights
github.com/aws/smithy-go: v1.28.3message/Messageon modeled JSON error structures in schema-based deserialization, and emit thesmithy.api#errortrait in generated schemasv1.28.2Compare Source
General Highlights
Module Highlights
github.com/aws/smithy-go: v1.28.2grpc-ecosystem/grpc-gateway (github.com/grpc-ecosystem/grpc-gateway/v2)
v2.32.0Compare Source
What's Changed
Configuration
📅 Schedule: (in timezone Etc/UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.