GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — feat: Add read_from and client_az options to the Redis GLIDE client by NopeCharon · Pull Request #7093 · feast-dev/feast

Conversation

@NopeCharon

@NopeCharon NopeCharon commented Oct 30, 2026

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:

The GLIDE client from #6870 always reads from the primary: the Feast config has no way to pass GLIDE's read strategy through, so clusters with replicas can't spread online reads across them.

This adds two RedisOnlineStoreConfig options that map directly onto GLIDE's own settings:

  • read_from: primary (default), prefer_replica, az_affinity, az_affinity_replicas_and_primary or all_nodes, translated to glide_sync.ReadFrom.
  • client_az: the client's availability zone, used by the az_affinity strategies.
online_store:
  type: redis
  redis_type: redis_cluster
  connection_string: "redis1:6379,redis2:6379"
  client: glide
  read_from: az_affinity
  client_az: us-east-1a

I used dedicated options rather than connection_string parameters, as the issue suggests. The reason is that connection_string parameters are also passed as kwargs to redis-py, which still handles writes and async reads, and redis-py would reject them.

The config is validated at load time, so a setting is never silently ignored:

  • read_from and client_az require client: glide, since redis-py doesn't use them.
  • A read_from other than primary requires redis_type: redis_cluster. A standalone GLIDE client sends every batch to the primary whatever read_from is, so the batched HMGET read would ignore the strategy. GLIDE's standalone BatchOptions has no routing option. I checked this against a real primary + replica: with PREFER_REPLICA, single hmget calls went to the replica but exec(Batch(...)) still went to the primary.
  • The az_affinity strategies require client_az. GLIDE also enforces this, but only when the client is created.

Docs: docs/reference/online-stores/redis.md gets a "Reading from replicas" section and two new rows in the configuration reference table.

Which issue(s) this PR fixes:

Fixes #7086

Checks

  • I've made sure the tests are passing.
  • My commits are signed off (git commit -s)
  • My PR title follows conventional commits format

Testing Strategy

  • Unit tests
  • Integration tests
  • Manual tests
  • Testing is not required for this change

Unit tests (tests/unit/infra/online_store/test_redis.py) cover the default, the three validation rules, and the mapping of every read_from value onto glide_sync.ReadFrom and client_az.

Manual test: I ran RedisOnlineStore.online_write_batch + online_read with client: glide against a Valkey 8 cluster with one primary (availability-zone zone-a) and one replica (zone-b). For each config I counted HMGET calls per node from INFO commandstats over one read of 3 entities:

config primary replica
default (primary) 3 0
prefer_replica 0 3
all_nodes 2 1
az_affinity, client_az: zone-b 0 3
az_affinity, client_az: zone-a (no replica in zone, falls back to other replicas) 0 3
az_affinity_replicas_and_primary, client_az: zone-a 3 0

All reads returned the written values.

Misc

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@NopeCharon
NopeCharon requested a review from a team as a code owner October 30, 2026 04:28
@codecov-commenter

codecov-commenter commented Oct 30, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.81%. Comparing base (bf74b10) to head (38df0e8).
⚠️ Report is 6 commits behind head on master.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7093      +/-   ##
==========================================
+ Coverage   51.79%   51.81%   +0.01%     
==========================================
  Files         458      458              
  Lines       57715    57735      +20     
  Branches     8483     8486       +3     
==========================================
+ Hits        29896    29915      +19     
  Misses      25793    25793              
- Partials     2026     2027       +1     
Flag Coverage Δ *Carryforward flag
go-feature-server 30.58% <ø> (ø) Carriedforward from bf74b10
python-unit 53.31% <100.00%> (+0.01%) ⬆️

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines Coverage Δ
sdk/python/feast/infra/online_stores/redis.py 70.56% <100.00%> (+1.33%) ⬆️

... and 1 file with indirect coverage changes


Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d904c27...38df0e8. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@shuchu

shuchu commented Nov 4, 2026

Copy link
Copy Markdown
Collaborator

@NopeCharon the PR is out-of-date, pls update it.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

shuchu
shuchu approved these changes Nov 4, 2026
View reviewed changes

@shuchu shuchu left a comment

Copy link
Copy Markdown
Collaborator

There was a problem hiding this comment.

Choose a reason for hiding this comment

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

lgtm

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@NopeCharon

NopeCharon commented Nov 4, 2026

Copy link
Copy Markdown
Contributor Author

Merged the latest master into the branch, no conflicts.

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@ntkathole
ntkathole force-pushed the feat/redis-glide-read-from branch from ce7ce13 to 4b075f3 Compare November 11, 2026 04:14
@ntkathole ntkathole added the ok-to-test label Nov 11, 2026
ntkathole
ntkathole approved these changes Nov 11, 2026
View reviewed changes
@NopeCharon @ntkathole
feat: Add read_from and client_az options to the Redis GLIDE client
38df0e8
The GLIDE client added in feast-dev#6870 always read from the primary, because
the Feast config had no way to pass GLIDE's read strategy through.
Clusters with replicas could not spread online reads across them.

Add two RedisOnlineStoreConfig options that map onto GLIDE's own
settings:

* read_from: primary (default), prefer_replica, az_affinity,
  az_affinity_replicas_and_primary or all_nodes, translated to
  glide_sync.ReadFrom.
* client_az: the client's availability zone, used by the az_affinity
  strategies.

The config is validated at load time so a setting can never be silently
ignored:

* read_from and client_az require client: glide, since redis-py does not
  use them.
* A read_from other than primary requires redis_type: redis_cluster. A
  standalone GLIDE client sends every batch to the primary, so the
  batched HMGET read would ignore the strategy.
* The az_affinity strategies require client_az, which GLIDE also
  enforces when building the client config.

Verified against a Valkey 8 cluster with one primary and one replica:
prefer_replica and az_affinity send the batched online_read to the
replica, all_nodes spreads it over both nodes, and the default keeps
reading from the primary.

Fixes feast-dev#7086

Signed-off-by: NopeCharon <[email protected]>
@ntkathole
ntkathole force-pushed the feat/redis-glide-read-from branch from 4b075f3 to 38df0e8 Compare November 11, 2026 14:36
@ntkathole
ntkathole merged commit 643b746 into feast-dev:master Nov 11, 2026
18 of 23 checks passed

Uh oh!

There was an error while loading. Please reload this page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@shuchu shuchu shuchu approved these changes
@ntkathole ntkathole ntkathole approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

ok-to-test

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

feat: Glide Client should support reading from replicas

Uh oh!

There was an error while loading. Please reload this page.

4 participants

@NopeCharon @codecov-commenter @shuchu @ntkathole
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.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.