deps(core-api): update sentry-sdk[fastapi] requirement from <3,>=2.66.0 to >=2.66.1,<3 in /core-api - #646
Open
dependabot[bot] wants to merge 1 commit into
Conversation
dependabot
Bot
added
area/core-api
Contributor
|
Claude Code Review — skipped: PR author 'dependabot[bot]' is not a public member of the 'caura-ai' org |
Updates the requirements on [sentry-sdk[fastapi]](https://github.com/getsentry/sentry-python) to permit the latest version. - [Release notes](https://github.com/getsentry/sentry-python/releases) - [Changelog](https://github.com/getsentry/sentry-python/blob/master/CHANGELOG.md) - [Commits](getsentry/sentry-python@2.66.0...2.66.1) --- updated-dependencies: - dependency-name: sentry-sdk[fastapi] dependency-version: 2.66.1 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
force-pushed
the
dependabot/uv/core-api/sentry-sdk-fastapi--gte-2.66.1-and-lt-3
branch
from
July 27, 2026 07:31
0975aea to
296071a
Compare
Contributor
|
Claude Code Review — skipped: PR author 'dependabot[bot]' is not a public member of the 'caura-ai' org |
Eldad-Caura
added a commit
that referenced
this pull request
Aug 10, 2026
… to (#740) Sets `versioning-strategy: increase-if-necessary` on the **uv entry only**, so a requirement in `pyproject.toml` is touched only when the new version actually falls outside it. ## Eight open PRs were doing nothing else The default (`increase`) raises the floor on every release even when the range already permits the new version: ``` uvicorn[standard] >=0.51.0,<1 → >=0.52.0,<1 for a version >=0.51.0,<1 already allowed ``` …once per service directory (#692, #693, #694, #695), plus #645, #646, #650, #691. **The `uv.lock` in all four directories was already being updated correctly** — the manifest edit on top was pure churn. Grouping can't absorb them: `update-types` classifies the semver bump of a *resolved version*, and a floor-raise on an already-satisfied range has no such classification. That's precisely why `uv-minor-patch` collapses the lock updates into one PR (#703, *"across 4 directories"*) while these arrive one at a time. ## Why this setting is right here and wrong elsewhere This is the same option I **rejected** for `caura-ops` two days ago, and the distinction is the whole point: | | this repo's `uv` entry | `caura-ops` | |---|---|---| | requirement shape | **capped** — 22 of 30 in `core-api` have an upper bound | open-ended `>=X`, no cap | | is "outside the range" reachable? | **yes** — uvicorn 1.0 vs `<1` still files a PR | never | | effect of this setting | de-duplicates churn | would have **silenced Python updates entirely** | | correct fix | this | commit a lock + switch ecosystem (done 2026-08-09) | ## Deliberately scoped The **`pip` entry in this same file is untouched.** It has mixed open-ended and capped requirements and no committed root lock, so it needs the `caura-ops` treatment and would be actively harmed by this setting. The file comment says exactly that, placed where someone would be tempted to copy the line. Verified the value is valid against the schema and that it landed on the `uv` entry alone — `pip`, both `npm` entries, `github-actions` and `docker` all remain on the default. ## Honest limit, and a cheap test **I could not confirm `increase-if-necessary`'s precise semantics from the docs** — that section of the options reference truncated on three separate fetches. This rests on the option name plus the observed capped-vs-open behaviour across these eight PRs. It's falsifiable next Monday: the scheduled run should produce **lock-only PRs with no `update X requirement from >=A to >=B` titles**. If widenings still appear, my reading is wrong and this is a one-line revert. I'd rather ship it with the test stated than assert it works. ## What to expect The eight open widening PRs become obsolete. Dependabot may supersede them on the next run; if not, they can be closed. The remaining five `caura-memclaw` widenings (#633–#637) come from the `pip` entry and need the separate lockfile change. @claude Signed-off-by: eldad-caura <eldad@caura.ai>
Eldad-Caura
added a commit
that referenced
this pull request
Aug 10, 2026
…is inert #740 set `versioning-strategy: increase-if-necessary` on the uv entry to stop Dependabot raising a requirement floor for a release the existing range already allowed. A live run disproved it. Merging #740 (09:01:46Z) triggered a re-run which closed #738 (01:41:47Z, so produced under the old config) and replaced it with #743 at 09:34:55Z. #743's manifest edits are identical in kind to #738's: `fastapi>=0.140.0,<1` became `>=0.141.1,<1` though 0.141.1 was already allowed, and the same shape held for alembic, cachetools, ruff, ddtrace and google-cloud-pubsub — 56 requirement lines across the four services. The eight individual widening PRs it was meant to retire (#645, #646, #650, #691, #692-#695) were left untouched. GitHub's options reference does list `uv` among the ecosystems supporting `versioning-strategy`, so this is a gap in dependabot-core rather than a config error here. Reverting to the default restores honest behaviour. The durable rule moves to the file header, where it governs the `pip` entry as well. That entry is where the setting would do real damage: with no committed lock, dependabot-core skips the manifest edit whenever the range already allows the release, which leaves nothing to change and so files no PR at all. Buried in the uv entry, that warning sat 36 lines away from the edit it exists to prevent. Net effect on the file is 7 lines shorter, and constraint-widening PRs are now recorded as a known, accepted cost rather than a solved problem. Signed-off-by: eldad-caura <eldad@caura.ai>
Eldad-Caura
added a commit
that referenced
this pull request
Aug 10, 2026
…is inert (#746) ## What Reverts the `versioning-strategy: increase-if-necessary` added to the `uv` entry in #740, and moves the durable rule to the file header. ## Why — #740 was falsified by its own first real run #740 shipped with a stated test: the setting should kill the eight individual widening PRs and leave lock-only PRs behind. The test ran, and it failed. The timing matters, because it is easy to read the evidence backwards: | when | what | |---|---| | 01:41:47Z | scheduled Monday `uv` run produces #738 — **old config** | | 09:01:46Z | #740 merges | | 09:34:55Z | config-change re-run closes #738, opens #743 — **new config** | So the scheduled run everyone was waiting on tested the config *before* the change. The only run that exercised `increase-if-necessary` is the one that produced #743, and #743's manifest edits are identical in kind to #738's: - `fastapi>=0.140.0,<1` → `>=0.141.1,<1` — 0.141.1 was already allowed - same shape for `alembic`, `cachetools`, `ruff`, `ddtrace`, `google-cloud-pubsub` - 56 requirement lines across the four services - the eight PRs it was meant to retire (#645, #646, #650, #691, #692-#695) were untouched, last updated 07-27 / 08-04 GitHub's options reference *does* list `uv` among the ecosystems supporting `versioning-strategy` ("Supported by: `bundler`, `cargo`, `composer`, `helm`, `mix`, `npm`, `pip`, `pub`, and `uv`"), so this is a gap in dependabot-core, not a mistake in the config. Reverting to the default restores honest behaviour: the file no longer claims to fix something it does not fix. ## Why the rule moved to the header The most valuable line in the old comment was the warning that the `pip` entry must never take this option — and it sat inside the `uv` entry, 36 lines from the edit it exists to prevent. On a lock-less entry the setting is worse than inert: dependabot-core skips the manifest edit when the new version already satisfies the range and no lockfile exists, so there is nothing left to change and **no PR is filed at all**. That is a silent loss of update coverage, and the warning now lives where both entries can see it. The header also records why `lockfile-only` is not the answer here: it is honoured, but it drops any update needing a manifest change, most specs in the uv services are capped, and this repo is public — these `>=` floors are part of the contract with OSS consumers, so a raised floor is not purely churn the way it is inside a private service. Constraint-widening PRs are now documented as a known, accepted cost rather than a solved problem. ## Notes - Config is 7 lines **shorter** than before #740; the point-in-time census numbers and the nine PR references are deliberately kept in this PR body rather than the config, where nothing fails when they go stale. - No behaviour change beyond restoring the Dependabot default. All six entries and all ten groups verified intact after the edit. Signed-off-by: eldad-caura <eldad@caura.ai>
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.
Updates the requirements on sentry-sdk[fastapi] to permit the latest version.
Release notes
Sourced from sentry-sdk[fastapi]'s releases.
Changelog
Sourced from sentry-sdk[fastapi]'s changelog.
... (truncated)
Commits
653a292Update CHANGELOG.mde20c226release: 2.66.14524b65fix(tracing): Stop settingNoOpSpanon scope in the streaming trace lifecyc...2e9f26eref(tracing): No-op and emit warning instart_transactionwith the streamin...3a50950fix(tracing): handle exceptions raised within traces_sampler and other callba...b5171b7ref: Use top-leveltrace_lifecycleandignore_spansoptions in tests (#6855)17e0348ref: Use old sampling context format in span streaming (#6848)2e09497test: Add streaming tests totest_http_headers(#6785)9996734feat(tracing): Sendsentry.segment.name.sourceinstead of `sentry.span.sour...00224f7remove span streaming docs in changelog (#6831)