fix: Handle connection errors during read operations. #163
Conversation
There was a problem hiding this comment.
When tests failed it would leave redis running, and then running tests again would require cleaning redis. This makes that a little more tolerable.
Note it would be better to try to do some trap exit like thing to always run a cleanup. It seems a little less than ideal to do directly in the makefile, but potentially we could move this step into a script and that would make it a bit better.
| {deps, [ | ||
| {bookish_spork, "0.3.5"}, | ||
| {cowboy, "2.8.0"}, | ||
| {cowboy, "2.10.0"}, |
There was a problem hiding this comment.
First, this is only for tests. But the very old version we were using was not compiling correct in OTP 28.
The latest version has dependency constraint problems with rebar3. You can use overrides to fix that, but then it isn't compatible with our tests. So updating this dependency to something newer will need to be its own work.
🤖 I have created a release *beep* *boop* --- ## [3.8.1](v3.8.0...v3.8.1) (2025-11-12) ### Bug Fixes * Handle connection errors during read operations. ([#163](#163)) ([5838c2b](5838c2b)) * Handle redis errors during mutations. ([#165](#165)) ([9dbe853](9dbe853)) * Prevent uninitialized SDK warning in daemon mode. ([#162](#162)) ([0961922](0961922)) * Redact SDK in gen_server descriptions and network errors. ([#166](#166)) ([3a4e005](3a4e005)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This PR adds error handling for read operations from the redis persistent store. This is an incremental step in addressing #161.
In the case we cannot read from redis, we will treat that as a flag not being found. If we cannot read from redis when doing an initialization check, then we will consider the store not to have been initialized.
This addresses the primary issues with daemon mode, but it doesn't address persistent store errors in non-daemon mode, or other cases that could cause the redis process to exit. Subsequent PRs will address these issues.
The detailed variation interface does not report why a flag cannot be found, and isn't the correct avenue for doing so, and as such we may have to consider supporting the data store status interface. This is also not tackled in this PR.