chore(deps): bump cpex-rate-limiter to 0.0.7#4608
Open
gandhipratik203 wants to merge 1 commit intomainfrom
Open
chore(deps): bump cpex-rate-limiter to 0.0.7#4608gandhipratik203 wants to merge 1 commit intomainfrom
gandhipratik203 wants to merge 1 commit intomainfrom
Conversation
…ening) Pulls in PR #78's production hardening of the Redis connection path on top of 0.0.6's TLS support. Wraps connection acquisition in a 2-second ``tokio::time::timeout`` so ``rediss://`` (or ``redis://``) endpoints that accept TCP but never respond at the application layer — TLS-required servers reached without TLS, network ACLs that drop post-handshake bytes, etc. — fail fast through the plugin's existing ``fail_mode`` path instead of hanging the request indefinitely. Three coordinated edits: - ``pyproject.toml:281`` — tighten min-version constraint ``cpex-rate-limiter>=0.0.6`` → ``>=0.0.7,<0.1.0``. The upper bound holds us at the 0.0.x line: 0.1.0 (also published today) is the matching half of an in-flight framework migration that pairs with mcp-context-forge#3754; until that lands, taking 0.1.0 alone would break plugin loading. - ``uv.lock`` — regenerated via ``uv lock --upgrade-package cpex-rate-limiter`` to pin the resolved version + per-platform wheel hashes for 0.0.7. - ``plugins/config.yaml:280`` — bump ``RateLimiterPlugin.version`` metadata from ``0.0.6`` to ``0.0.7`` so the shipped sample config reflects the wheel version operators actually load. This field is operator-facing metadata mirrored from the plugin's ``plugin-manifest.yaml``; not a dependency constraint. The existing date pin (``2026-05-31T23:59:59Z``) already covers 0.0.7's upload (2026-05-05T13:10:33), so no date-pin change is needed. Verified locally: ``uv sync --extra plugins`` installs 0.0.7 cleanly, ``cpex_rate_limiter.rate_limiter.RateLimiterPlugin`` imports without error, and the plugin-framework loader unit tests stay green (27 passed). Signed-off-by: Pratik Gandhi <gandhipratik203@gmail.com>
gandhipratik203
requested review from
brian-hussey and
crivetimihai
as code owners
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
1 participant
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.
Summary
Bump
cpex-rate-limiterfrom 0.0.6 to 0.0.7 to pull in the production-hardening release from cpex-plugins#78.Changes
pyproject.toml:cpex-rate-limiter>=0.0.6→>=0.0.7,<0.1.0. Upper bound holds us at the 0.0.x line; 0.1.0 (also published today) is the matching half of the framework migration in feat: replace the internal plugin framework with CPEX #3754 and shouldn't land alone.uv.lock: regenerated viauv lock --upgrade-package cpex-rate-limiter.plugins/config.yaml: bumpRateLimiterPlugin.versionmetadata from0.0.6to0.0.7.Test plan
uv sync --extra pluginsinstalls 0.0.7 cleanlytest/tls-redis-smoke-teststack