Fix View instrument-name matching to be case-insensitive and platform-independent#5430
Open
winklemad wants to merge 1 commit into
Open
Fix View instrument-name matching to be case-insensitive and platform-independent#5430winklemad wants to merge 1 commit into
winklemad wants to merge 1 commit into
Conversation
|
|
…istic Instrument names are valid mixed-case (the API regex allows [a-zA-Z]...), but the SDK lower-cases them on construction (_Synchronous/_Asynchronous set self.name = name.lower()). View._match compared the user's instrument_name pattern against that lower-cased name with fnmatch, without lower-casing the pattern, so a View built with the instrument's real name (e.g. View(instrument_name="MyLatency")) silently failed to match and its aggregation/drop/rename/attribute filter was ignored. fnmatch also applies os.path.normcase, which lower-cases on Windows but is identity on POSIX, so the same View matched on Windows but not on Linux/macOS. Lower-case the name pattern (matching the SDK's own lower-casing) and use fnmatchcase for both name and unit so matching no longer depends on the host platform's filename case sensitivity. Units stay case-sensitive, per UCUM. Assisted-by: Claude (Anthropic)
winklemad
force-pushed
the
fix-view-instrument-name-case
branch
from
July 17, 2026 16:15
4814fa8 to
64d11a0
Compare
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.
Description
A
Viewbuilt with an instrument's real, documented name silently fails to match, so its aggregation / drop / rename / attribute filter is never applied.Instrument names are valid mixed-case (the API name regex is
[a-zA-Z][-_./a-zA-Z0-9]{0,254}), but the SDK lower-cases them on construction (_Synchronous/_Asynchronoussetself.name = name.lower()).View._matchcompared the user'sinstrument_namepattern against that lower-cased name withfnmatchwithout lower-casing the pattern:There's a second problem at the same spot:
fnmatchappliesos.path.normcase, which lower-cases on Windows but is identity on POSIX — so the same View matches on Windows and not on Linux/macOS.Fix
Lower-case the name pattern (matching the SDK's own lower-casing, so names match case-insensitively as the duplicate-instrument-name check at #2409 already assumes), and use
fnmatchcasefor both the name and unit sites so matching no longer depends on the host platform. Units stay case-sensitive (per UCUM).Test
Added
test_instrument_name_case_insensitiveandtest_instrument_unit_case_sensitivetotest_view.py; they fail on the previous code and pass with the fix.test_view.py→ 11 passed.Disclosure: this change was written with AI assistance (noted via an
Assisted-by:commit trailer, per the project's guidance); I've reviewed and verified every line and the reproduction.