Open
Conversation
1fc5118 to
1daacdf
Compare
b0f229e to
ba1f692
Compare
Author
ℹ️ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
ba1f692 to
46c0ede
Compare
798a8e0 to
30de259
Compare
30de259 to
6e5fc27
Compare
c811adf to
33fbe26
Compare
fc795a0 to
27e404f
Compare
5095b8c to
6fee5b9
Compare
6fee5b9 to
5e3599b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v0.19.2→v0.21.0v2.4.0→v2.5.0v1.2.0→v1.2.1v2.3.0→v2.3.4v1.20.5→v1.20.7v1.17.1→v1.17.2v1.12.0→v1.13.1v0.19.0→v0.20.0Release Notes
adobe/ims-go (github.com/adobe/ims-go)
v0.21.0Compare Source
v0.20.0Compare Source
go-viper/mapstructure (github.com/go-viper/mapstructure/v2)
v2.5.0Compare Source
What's Changed
New Contributors
Full Changelog: go-viper/mapstructure@v2.4.0...v2.5.0
knadh/koanf (github.com/knadh/koanf/providers/file)
v1.2.1Compare Source
changelog for v1.2.0 -> v1.2.1
29cce50Merge pull request #101 from e-nikolov/fix-pflag-map-types0202243posflag: add support for pflag map typestwmb/franz-go (github.com/twmb/franz-go)
v1.20.7Compare Source
===
This patch release fixes numerous niche bugs - some user reported, some found
while investigating other things - contains a few behavior improvements,
extensive kfake additions, and many test additions / improvements.
There have been extensive additions to kfake over the course of the past
month; kfake now supports transactions, the next generation consumer group
protocol, and more Kafka APIs. franz-go integration tests now run and pass
against kfake in CI.
Testing has further been extensively improved: integration tests now run
against the latest patch version of Kafka for all major Kafka versions going
back to 0.11.0. The existing test suite has been extended to run while opting
into the next generation consumer group. An integration test against Kerberos
has been added. For ~roughly the past year (maybe half year), all bugs found
have had regression tests added in kfake. This release massively extends the
kfake test suite -- both with behavior tests that were ported via Claude
directly to franz-go (with license attribution!) and with behavior tests that
Claude generated specifically for kfake.
The "next generation" (KIP-848) consumer group code in franz-go itself has some
improvements. These improvements were found after adding 848 code to kfake,
which allowed for much faster integration test looping. This looping was still
very slow for what it's worth; towards the end, integration tests would pass
~40+ times with race mode over the course of two hours before failing once.
Claude was instrumental with adding appropriate log lines and tracing logs for
diagnosing extremely niche failures; things also got slower when a few specific
log lines that would've helped weren't added the first time...
Anyway,
Bug fixes
Returns from PollRecords / PollFetches that contained ONLY an error (context
cancellation or something) previously did not block rebalances, even if you
opted into BlockRebalanceOnPoll.
If, while idempotently producing, the client encountered
TIMED_OUTwhileproducing (retryable), the client considered this a "we definitively did not
produce" state, and allowed you to cancel the records. Well, maybe the records
actually did get produced broker side eventually, and now you re-produce new
records - the NEW records could be "deduplicated" due to how idempotency works.
This one is a bit niche, if you're interested, you should read #1217 and the
two PRs that address it.
My original implementation of how Kerberos handled authentication was
correct... for the time. I missed how it should have been touched up years
ago and now 4.0 hard deprecates the old auth flow. So, that's been found,
reported, and now fixed.
If a partition returned a retryable error in a metadata request (odd behavior
already) the first time the client is discovering the partition (i.e. on
startup), the client would not retry loading the partition right away (it
would, but much later on standard metadata refresh).
There was a very subtle, basically un-encounterable data race while
consuming. That was fixed in
5caaa1e0. It's so niche it's not worthwriting more about here.
RequestCachedMetadata, broken for a few releases, has been fixed. I plan toswitch kadm back to using it in the next kadm release.
There was a data race on client shutdown while leaving the group if you canceled
the client context.
Improvements
ConnIdleTimeoutis now obeyed more exactly, allowing you to more reliably reasonabout the maximum idle time. Thanks @carsonip!
At the end of a group transact session, I force a heartbeat to kinda "force
detect" the group is still alive (with some timing bounds). If the heartbeat
detected any error - including
REBALANCE_IN_PROGRESS- the session wouldabort no matter what. This has been changed to actually allow a commit (if
that's what you're doing) in certain scenarios (notably: the client detects
KIP-447 support on the broker and you are using RequireStable).
SetOffsets now does not let you set offsets for partitions that are not being
consumed. Previously, you could, but it'd just create entries in a map that were
never used. Those entries are no longer created.
ProduceSync now automatically un-lingers any partition that is produced to,
causing more immediate flushes. This should resolve lag that was introduced
from v1.20.0 where linger was set to 10ms by default. There are many usages of
franz-go I've seen in the wild where ProduceSync is used in random places to
produce one message before going back to other things.
764eb29dimprovement kgo: unlinger partitions in ProduceSync to avoid linger delayd996bf71bugfix kgo: fix data race during client shutdown with canceled context85b2c855behavior change kgo: fix applySetOffsets to skip partitions not being consumed05de202bimprovement kgo: allow commit despite rebalance with KIP-447 and RequireStablee8a00cd6improvement kgo: do not reuse idle connection after connIdleTimeout (thanks @carsonip!)787ab9febugfix kgo: fix and enhance RequestCachedMetadata5caaa1e0bugfix kgo: fix data race in allowUsable reading c.source after Swap40c144d3bugfix kgo: check loadErr for new partitions on first metadata loade430ea93bugfix kgo: send SaslHandshake for GSSAPI mechanism702c4f75bugfix kgo: error returns from polling should block rebalance32e1580a0c086b05bugfix kgo: poison batches to prevent future cancelation on two errorsv1.20.6Compare Source
===
This patch release has two improvements.
Previously, you could not use poll functions multiple times if using
BlockRebalanceOnPoll, because rebalancing had a higher lock priority thanpolling and would block all further poll calls. This has been changed to allow
you to call poll as much as you want until you
AllowRebalance. Thanks@KiKoS0!
If brokers indicated they supported epochs, but then used -1 everywhere for
that epoch,
Markfunctions would ignore records being marked and you wouldnever commit progress. This was due to the client defaulting to a 0 epoch
internally (and not using it if the broker did not support it), meaning -1
would be ignored. Brokers that use indicate support but use -1 are now
supported. This was only found to be a problem against Azure Event Hubs.
7cd5ea65kgo: fix mark <=> epoch interaction, make epoch handling more resilient94fd8622kgo: fix deadlock when polling multiple times while blocked from a rebalanceConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, 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.