Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make connection retry timeout default consistent #105

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

JetForMe
Copy link
Member

Fix for #104. Makes the connection retry timeout consistent regardless of whether no value is specified, or nil is specified.

Test failures seem to be due to the specific test comparing floats:

Test Suite 'StringCommandsTests' failed at 2024-03-20 15:05:53.225.
Executed 17 tests, with 2 failures (0 unexpected) in 0.576 (0.577) seconds
Test Suite 'RediStackPackageTests.xctest' failed at 2024-03-20 15:05:53.225.
Executed 264 tests, with 2 failures (0 unexpected) in 38.703 (38.716) seconds
Test Suite 'All tests' failed at 2024-03-20 15:05:53.225.
Executed 264 tests, with 2 failures (0 unexpected) in 38.703 (38.717) seconds

…/RediStack/Tests/RediStackIntegrationTests/Commands/StringCommandsTests.swift:212: error: -[RediStackIntegrationTests.StringCommandsTests test_incrementByFloat] : XCTAssertEqual failed: ("3.1479989999999987") is not equal to ("3.147999")
…/RediStack/Tests/RediStackIntegrationTests/Commands/StringCommandsTests.swift:214: error: -[RediStackIntegrationTests.StringCommandsTests test_incrementByFloat] : XCTAssertEqual failed: ("18.441798999999996") is not equal to ("18.441799")

Makes the connection retry timeout consistent regardless of whether no value is specified, or `nil` is specified.
Copy link
Member

@Joannis Joannis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. @fabianfett how can I trigger CI with the current setup?

@0xTim
Copy link
Member

0xTim commented Apr 24, 2024

@swift-server-bot please test

@0xTim
Copy link
Member

0xTim commented Apr 26, 2024

@swift-server-bot test

1 similar comment
@0xTim
Copy link
Member

0xTim commented Apr 26, 2024

@swift-server-bot test

@0xTim
Copy link
Member

0xTim commented Apr 26, 2024

@swift-server-bot please test

@0xTim
Copy link
Member

0xTim commented Apr 26, 2024

@swift-server-bot add to allowlist

@JetForMe
Copy link
Member Author

I'm not sure what the tests are trying to do here, but I notice that only "soundness," 5.6, 5.7, and 5.8 have a "required" label, but the rest do not (in particular, 5.9 and 5.10).

@JetForMe
Copy link
Member Author

Welp, my code no longer builds. I'm not sure why. Let me fix it.

@JetForMe
Copy link
Member Author

@0xTim Sorry about that, not sure what happened. But all’s good now, I think.

@JetForMe
Copy link
Member Author

@Joannis I think this is good to go?

@@ -134,7 +136,7 @@ extension RedisConnectionPool {
self.minimumConnectionCount = minimumConnectionCount
self.connectionRetryConfiguration = (
(initialConnectionBackoffDelay, connectionBackoffFactor),
connectionRetryTimeout ?? .milliseconds(10) // always default to a baseline 10ms
connectionRetryTimeout ?? Self.defaultConnectionRetryTimeout
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a breaking change. Explicitly passing nil currently leads to a timeout of 10ms. We would change that to 60sec. This can lead to unexpected behavior for adopters.

Copy link
Member

@fabianfett fabianfett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for taking so long to review this. Thanks for raising the issue and providing a potential fix.

While I agree that #104 absolutely has a point, I think that this change is a breaking behavior change, that we should not go forward with today. This issue can only be fixed in the next major. Adopters have a clear way around this issue, by passing an explicit value or omitting the parameter. Just explicitly passing nil is currently a bad option.

@JetForMe
Copy link
Member Author

While I am generally loathe to make breaking changes, I’m not sure in this case it’s cut-and-dry. Here are my thoughts.

  • When is the next major release?
  • The current behavior has bitten at least a few people that I know of.
  • 10 ms seems like an impossibly small timeout; where did it originate? The other default timeout is 100 ms, as it meant to be that?
  • Even in very high performance systems (where a connection rarely times out), would anyone deliberately rely on such a short timeout? If someone wasn't already working around this by setting a longer timeout, would suddenly having a longer one adversely affect them? I get that we can't say for certain, but what's the likelihood, in a conceivable system, that it would?

At the very least, the documentation and example should make it clear this is an issue.

@0xTim
Copy link
Member

0xTim commented May 4, 2024

It's also not a breaking change - it's a change in behaviour for sure but code will still compile which is what SemVer defines as breaking changes. Whether it should be accepted is still a question for the maintainers though

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants