build(deps): bump github.com/twmb/franz-go from 1.3.1 to 1.3.3 #167

Closed
dependabot[bot] wants to merge 1 commits from dependabot/go_modules/github.com/twmb/franz-go-1.3.3 into master
dependabot[bot] commented 2022-02-16 17:17:36 +03:00 (Migrated from github.com)

Bumps github.com/twmb/franz-go from 1.3.1 to 1.3.3.

Changelog

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

v1.3.3

This patch release contains two minor bug fixes and a few small behavior changes. The upcoming v1.4 release will contain more changes to lint the entire codebase and will have a few new options as features to configure the client internals. There are a few features in development yet that I would like to complete before tagging the next minor release.

Bug fixes

Repeated integration testing resulted in a rare data race, and one other bug was found by linting. For the race, if a group was left or heartbeating stopped before offset fetching finished, then there would be a concurrent double write to an error variable: one write would try to write an error from the request being cut (which would be context.Canceled), and the other write would write the same error, but directly from ctx.Err. Since both of these are the same type pointer and data pointer, it is unlikely this race would result in anything if it was ever encountered, and encountering it would be rare.

For the second bug, after this prior one, I wondered if any linter would have caught this bug (the answer is no). However, in the process of heavily linting the code base, a separate bug was found. This bug has no impact, but it is good to fix. If you previously consumed and specified exact offsets to consume from, the internal ListOffsets request would use that offset as a timestamp, rather than using -1 as I meant to internally. The whole point is just to load the partition, so using a random number for a timestmap is just as good as using -1, but we may as well use -1 to be proper.

Behavior changes

Previously when producing, the buffer draining goroutine would sleep for 50ms whenever it started. This was done to give high throughput producers a chance to produce more records within the first batch, rather than the loop being so fast that one record is in the first batch (and more in the others). This 50ms sleep is a huge penalty to oneshot producers (producing one message at a time, synchronously) and also was a slight penalty to high throughput producers whenever the drain loop quit and needed to be resumed. We now eliminate this sleep. This may result in more smaller batches, but definitely helps oneshot producers. A linger can be used to avoid small batches, if needed.

Previously, due to MS Azure improperly replying to produce requests when acks were zero, a discard goroutine was added to drain the produce connection if the client was configured to produce with no acks. Logic has been added to quit this goroutine if nothing is read on that goroutine for 3x the connection timeout overhead, which is well enough time that a response should be received if the broker is ever going to send one.

Previously, MarkCommitRecords would forbid rewinds and only allow advancing

... (truncated)

Commits
  • c67ef7e CHANGELOG: note v1.3.3
  • 89f9425 client: fix outdated documentation
  • b39ca31 fetchOffsets: fix data race
  • 4156e9f kgo: fix one bug found by linting
  • ad991d8 franz-go: bump kmsg dependency for v9 SkipAssignment fix
  • ef99f29 kmsg: tag SkipAssignment as v9+
  • a05b6b2 kgo: add support for KIP-814
  • 72760bf kversion/kmsg: add SkipAssignment to JoinGroupResponse (KIP-814)
  • c241399 config: temporarily comment out new API for v1.3.3 release
  • db9017a broker: allow the discard goroutine to die
  • Additional commits viewable in compare view

Dependabot compatibility score

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 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)
Bumps [github.com/twmb/franz-go](https://github.com/twmb/franz-go) from 1.3.1 to 1.3.3. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/twmb/franz-go/blob/master/CHANGELOG.md">github.com/twmb/franz-go's changelog</a>.</em></p> <blockquote> <h1>v1.3.3</h1> <p>This patch release contains two minor bug fixes and a few small behavior changes. The upcoming v1.4 release will contain more changes to lint the entire codebase and will have a few new options as features to configure the client internals. There are a few features in development yet that I would like to complete before tagging the next minor release.</p> <h2>Bug fixes</h2> <p>Repeated integration testing resulted in a rare data race, and one other bug was found by linting. For the race, if a group was left <em>or</em> heartbeating stopped <em>before</em> offset fetching finished, then there would be a concurrent double write to an error variable: one write would try to write an error from the request being cut (which would be <code>context.Canceled</code>), and the other write would write the same error, but directly from <code>ctx.Err</code>. Since both of these are the same type pointer and data pointer, it is unlikely this race would result in anything if it was ever encountered, and encountering it would be rare.</p> <p>For the second bug, after this prior one, I wondered if any linter would have caught this bug (the answer is no). However, in the process of heavily linting the code base, a separate bug was found. This bug has <strong>no impact</strong>, but it is good to fix. If you previously consumed and specified <em>exact</em> offsets to consume from, the internal <code>ListOffsets</code> request would use that offset as a timestamp, rather than using -1 as I meant to internally. The whole point is just to load the partition, so using a random number for a timestmap is just as good as using -1, but we may as well use -1 to be proper.</p> <h2>Behavior changes</h2> <p>Previously when producing, the buffer draining goroutine would sleep for 50ms whenever it started. This was done to give high throughput producers a chance to produce more records within the first batch, rather than the loop being so fast that one record is in the first batch (and more in the others). This 50ms sleep is a huge penalty to oneshot producers (producing one message at a time, synchronously) and also was a slight penalty to high throughput producers whenever the drain loop quit and needed to be resumed. We now eliminate this sleep. This may result in more smaller batches, but definitely helps oneshot producers. A linger can be used to avoid small batches, if needed.</p> <p>Previously, due to MS Azure improperly replying to produce requests when acks were zero, a discard goroutine was added to drain the produce connection if the client was configured to produce with no acks. Logic has been added to quit this goroutine if nothing is read on that goroutine for 3x the connection timeout overhead, which is well enough time that a response should be received if the broker is ever going to send one.</p> <p>Previously, <code>MarkCommitRecords</code> would forbid rewinds and only allow advancing</p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/twmb/franz-go/commit/c67ef7e570587cf0bd34434fb7aa7c1e34f26045"><code>c67ef7e</code></a> CHANGELOG: note v1.3.3</li> <li><a href="https://github.com/twmb/franz-go/commit/89f94256d65a96865d294f21c63948fae0e7309b"><code>89f9425</code></a> client: fix outdated documentation</li> <li><a href="https://github.com/twmb/franz-go/commit/b39ca311e5c1775250e981bbf28f0e06084f2eff"><code>b39ca31</code></a> fetchOffsets: fix data race</li> <li><a href="https://github.com/twmb/franz-go/commit/4156e9f73ae31338ed98589d93d22036f7349d7f"><code>4156e9f</code></a> kgo: fix one bug found by linting</li> <li><a href="https://github.com/twmb/franz-go/commit/ad991d8eaabebae7ed32232868a238c945bb7208"><code>ad991d8</code></a> franz-go: bump kmsg dependency for v9 SkipAssignment fix</li> <li><a href="https://github.com/twmb/franz-go/commit/ef99f297bf9b917b205bc4a9562ee925a7d59756"><code>ef99f29</code></a> kmsg: tag SkipAssignment as v9+</li> <li><a href="https://github.com/twmb/franz-go/commit/a05b6b2c7a69bfec03ff3bf15e56c93486f7958c"><code>a05b6b2</code></a> kgo: add support for KIP-814</li> <li><a href="https://github.com/twmb/franz-go/commit/72760bf2e9a60c382f7ab62cf0f9c97e5bdab9a3"><code>72760bf</code></a> kversion/kmsg: add SkipAssignment to JoinGroupResponse (KIP-814)</li> <li><a href="https://github.com/twmb/franz-go/commit/c241399c2fd549223b24f888ac3e66c6c999388d"><code>c241399</code></a> config: temporarily comment out new API for v1.3.3 release</li> <li><a href="https://github.com/twmb/franz-go/commit/db9017a8a5229b2a720103ef78806ffdaa38e2e6"><code>db9017a</code></a> broker: allow the discard goroutine to die</li> <li>Additional commits viewable in <a href="https://github.com/twmb/franz-go/compare/v1.3.1...v1.3.3">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=github.com/twmb/franz-go&package-manager=go_modules&previous-version=1.3.1&new-version=1.3.3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> 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 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) </details>
vtolstov (Migrated from github.com) approved these changes 2022-02-16 17:17:51 +03:00
dependabot[bot] commented 2022-02-22 17:29:25 +03:00 (Migrated from github.com)

Superseded by #169.

Superseded by #169.

Pull request closed

Sign in to join this conversation.
No description provided.