⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6689   +/-   ##
=======================================
  Coverage   46.80%   46.81%           
=======================================
  Files         415      415           
  Lines       50395    50396    +1     
  Branches     7214     7214           
=======================================
+ Hits        23587    23591    +4     
+ Misses      25155    25154    -1     
+ Partials     1653     1651    -2     

@ntkathole @franciscojavierarceo
This has been green since Friday with no reviewer assigned. It's a small docs correction: _validate_token doesn't validate anything beyond decoding, so the docstring and the guide both overstate what it does.

Could one of you take a look, or route it to whoever owns this area? It also needs a kind/ label, which I can't add as an outside contributor.

@ntkathole
It was, yes. Renamed it to _check_discovery_endpoints, which is what the docstring's first line already said it does. Leaving the old name meant the docstring had to open by correcting the name, which is a smell in itself.

It's private with a single caller in the same file, so the rename is contained. I kept the access_token parameter because the bearer scheme still needs a well-formed Authorization header, and the caller has the token to hand. Happy to drop it and pass a placeholder if you'd rather make that explicit too, since the value provably can't affect the outcome.

317 permissions tests pass.

@ntkathole @franciscojavierarceo
Still open. Your naming question was addressed on 5 August: _validate_token became _check_discovery_endpoints, which is what the docstring's first line already said it does.

The red check is worth explaining, because it isn't this PR and it looks alarming. unit-test-python (3.12, ubuntu-latest) failed on test_3rd_party_providers with:

ModuleNotFoundError: No module named 'psutil'

That's a race inside the test suite, not a missing dependency. tests/unit/infra/test_dependency_conflicts.py runs pip install kserve==0.15.2 against the live interpreter with no isolation. feast pins psutil==5.9.0 and kserve requires psutil<6.0.0,>=5.9.6, so pip cannot leave the existing version in place: it uninstalls psutil, then installs 5.9.8. I reproduced that locally and the pip log shows the window plainly.

The suite runs under xdist with 8 workers sharing one environment, so any concurrently running test that shells out to the feast CLI can land in that window and find no psutil. test_3rd_party_providers does exactly that. In this run the kserve test finished at 12:25:54 and the failure came at 12:29:15 in the same job. It's timing-dependent, which is why it's intermittent rather than reproducible on demand.

Two things worth flagging beyond this PR. Mutating the interpreter that's running the suite makes any test that shells out nondeterministic, so a re-run will probably go green without anything having changed. And separately, #6713 loosens psutil==5.9.0 to >=5.9.0 for unrelated reasons; if the lock then resolves psutil into kserve's range, pip would have nothing to uninstall and this race would close as a side effect.

Happy to open an issue for the isolation problem if that's useful. Otherwise this PR is a one-line rename plus a docstring, with no conflicts against current master.