build(deps): bump github.com/twmb/franz-go from 1.18.0 to 1.18.1

[dependabot]

Bumps github.com/twmb/franz-go from 1.18.0 to 1.18.1.

Changelog

Sourced from github.com/twmb/franz-go's changelog.

v1.18.1

This patch release contains a myriad of fixes for relatively minor bugs, a few improvements, and updates all dependencies. Both pkg/kadm and pkg/sr are also being released as minors in tandem with a few quality of life APIs.

Bug fixes

• Previously, if records were successfully produced but returned with an invalid offset (-1), the client would erroneously return bogus offsets to the end users. This has been fixed to return -1. (Note this was never encountered in the wild).

• Pausing topics & partitions while using PollRecords previously could result in incorrect accounting in BufferedFetchRecords and BufferedFetchBytes, permanently causing the numbers returned to be larger than reality. That is, it is possible the functions would return non-zero numbers even though nothing was buffered.

• When consuming from a follower (i.e. you were using the Rack option and your cluster is configured with follower fetching), if the follower you consumed from had a higher log start offset than the leader, and if you were trying to consume from an early offset that exists on the leader but not on the follower, the client would enter a permanent spinloop trying to list offsets against the follower. This is due to KIP-320 case 3, which mentions that clients should send a ListOffsets to the follower -- this is not the case, Kafka actually returns NotLeaderOrFollower when sending that request to the follower. Now the client clears the preferred replica and sends the next fetch request to the leader, at which point the leader can either serve the request or redirect back to a different preferred replica.

Improvements

• When finishing batches, if any records were blocked in Produce due to the client hitting the maximum number of buffered records, the client would broadcast to all waiters that a message was finished for every message finished until there were no other goroutines waiting to try to produce. When lingering is enabled, linger occurs except when the client has reached the maximum number of buffered records. Once the client is as max buffered records, the client tries to flush until more records can be buffered. If you have a few concurrent producers, they will all hang trying to buffer. As soon as one is signaled, it will grab the free spot, enter into the client as buffered, and then see the client is now again at max buffered and immediately create a batch rather than lingering. Thus, signalling one at a time would cause many small single-record batches to be created and each cause a round trip to the cluster. This would result in slow performance. Now, by finishing a batch at a time, the client opens many slots at a time for any producers waiting, and ideally they can fit into being buffered without hitting max buffered and clearing any linger state. Note that single-message batches can still cause the original behavior, but there is not much more that can be done.

• Decompression errors encountered while consuming are now returned to the end user, rather

... (truncated)

Commits

• 6ea03e3 Merge pull request #893 from twmb/changelog-v1.18.1
• 6a63914 CHANGELOG: note incoming v1.18.1
• 9e81865 Merge pull request #892 from twmb/deps
• 79debef generate: remove untrue doc line
• 64fea5c franz-go: bump deps
• 868fe79 bump-deps: bump max lang supported
• 6c955bf deps: bump pkg/ (submodules)
• f2ddd13 deps: bump plugin/
• 01758cd deps: bump exampls/
• 237dc07 Merge pull request #891 from twmb/kadm-auth-ops
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

commit hash: 5428e1b
openapi.yaml

Lint Result

Lint: docs/api.yaml

Severity	Location	Problem	Message
warning	line 10:10	no-server-example.com	Server url should not point to example.com or localhost.

Validation successful
Warnings: 1

[github-actions]

commit hash: 3b38c31
openapi.yaml

Lint Result

Lint: docs/api.yaml

Severity	Location	Problem	Message
warning	line 10:10	no-server-example.com	Server url should not point to example.com or localhost.

Validation successful
Warnings: 1

[github-actions]

commit hash: 3070780
openapi.yaml

Lint Result

Lint: docs/api.yaml

Severity	Location	Problem	Message
warning	line 10:10	no-server-example.com	Server url should not point to example.com or localhost.

Validation successful
Warnings: 1