fix: context-aware API discovery now works with datumctl#570
Merged
Conversation
The Milo API server returns plain application/json for aggregated discovery responses instead of the expected media type containing as=APIGroupDiscoveryList. Fall back to inspecting the response body's kind field so the filter correctly handles the aggregated path. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
Check the request Accept header for as=APIGroupDiscoveryList rather than the response Content-Type. kubectl always sends this in the Accept header, but Milo returns plain application/json in the response so checking the response header was unreliable. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changed
When you run
datumctl api-resources, the list of resources is now correctly filtered based on your current context — so you only see what's relevant to where you are (organization, project, or user).Why it wasn't working
The previous release (#567) introduced context-aware discovery filtering. It worked correctly when tested via direct HTTP calls, but
datumctl api-resourceswas still showing everything regardless of context.The root cause: the filter was checking the response
Content-Typeheader to detect the discovery format. In standard Kubernetes, the server echoes back the requested format inContent-Type— but Milo returns plainapplication/json, so the filter never recognized the format and skipped filtering entirely.The fix
kubectl always declares the format it wants via the request
Acceptheader. The filter now checks that instead, which is both more reliable and simpler — no dependency on what the server echoes back.🤖 Generated with Claude Code