Daily security sweep — backlog

Tracking issue for advisories in langchain/uv.lock that the daily security sweep could not clear, so they are not silently lost. Updated per run.

Context: Dependabot is not scanning this repo

GET /repos/vectorize-io/integrations-python/dependabot/alerts returns HTTP 200 with an empty array in every state (open, fixed, dismissed, auto_dismissed) while langchain/uv.lock is committed — the repo has never been scanned, so there are no alert numbers anywhere in this issue, only GHSA/CVE ids.

Action for a maintainer: enable Dependabot alerts under Settings -> Code security. Until then this repo is invisible to it and every sweep has to re-derive the advisory set by hand with uv export | uvx pip-audit.

2026-09-02

Baseline on main: 23 findings across 8 packages (uvx pip-audit, py3.13 resolution leg).

Shipped: #10 (12 advisories: h11, idna, orjson, requests, urllib3, pytest) and #11 (9 advisories: langchain-core, langsmith — major, needs review).

No check failed; nothing was backlogged for a build failure. What follows is backlogged because no upgrade path exists, not because anything broke.

Root cause of everything below: `requires-python = ">=3.9"`

Python 3.9 has been EOL since October 2025 and every fix listed here dropped 3.9 support. The lock therefore resolves two legs, and the 3.9 leg cannot be made clean at any version. Concretely, after #10 + #11 the py3.9 leg still carries:

package	best available on py3.9	still open	fix version	fix requires
urllib3	2.6.3	GHSA-qccp-gfcp-xxvc (CVE-2026-44431)	2.7.0	py>=3.10
urllib3	2.6.3	GHSA-mf9v-mfxr-j63j (CVE-2026-44432)	2.7.0	py>=3.10
requests	2.32.5	GHSA-gc5v-m9x4-r6x2 (CVE-2026-25645)	2.33.0	py>=3.10
orjson	3.11.5	GHSA-hx9q-6w63-j58v (CVE-2025-67221)	3.11.6	py>=3.10
pytest (dev)	8.4.2	GHSA-6w46-j5rx-g56g (CVE-2025-71176)	9.0.3	py>=3.10
langchain-core	0.3.86	GHSA-qh6h-p6c9-ff54 (CVE-2026-34070)	1.2.22	py>=3.10
langchain-core	0.3.86	GHSA-2g6r-c272-w58r (CVE-2026-26013)	1.2.11	py>=3.10
langsmith	0.4.37	GHSA-3644-q5cj-c5c7 (CVE-2026-45134)	0.8.0	py>=3.10
langsmith	0.4.37	GHSA-rr7j-v2q5-chgv (CVE-2026-41182)	0.7.31	py>=3.10
langsmith	0.4.37	GHSA-v34v-rq6j-cj6p (CVE-2026-25528)	0.6.3	py>=3.10
langsmith	0.4.37	GHSA-f4xh-w4cj-qxq8	0.8.18	py>=3.10

Proposed fix: drop Python 3.9. Remove it from requires-python, the classifiers block in langchain/pyproject.toml, and the matrices in .github/workflows/python_test.yml and lint.yml. That collapses the two resolution legs into one and clears every advisory above. It is an API-compatibility decision for the published langchain-vectorize package, so the sweep will not make it unilaterally.

Two regressions introduced on the py3.9 leg (accepted knowingly)

Both are cases where the newest 3.9-compatible version is itself vulnerable, and staying put would have been worse overall:

urllib3 2.3.0 -> 2.6.3 introduces GHSA-mf9v-mfxr-j63j (introduced in 2.6.0, fixed in 2.7.0). It clears 5 other urllib3 advisories in exchange, so 6 -> 2.
langsmith 0.3.15 -> 0.4.37 (forced by chore(security): bump langchain-core 0.3.45 -> 1.6.1 (9 advisories) - MAJOR, needs review #11: langchain-core 0.3.86 requires langsmith>=0.3.45) introduces GHSA-v34v-rq6j-cj6p (introduced in 0.4.10, fixed in 0.6.3). This one is a genuine net negative for the 3.9 leg: 3 -> 4. It is unavoidable while both langchain-core 0.3.86 and py3.9 are in play, and disappears entirely if 3.9 is dropped.

Note on local verification

langchain/tests/test_retrievers.py is a live integration suite, not a unit suite — its session fixture raises ValueError: Please set the VECTORIZE_TOKEN environment variable. It cannot be executed outside CI, on main or on any branch. Sweep verification is therefore limited to uv sync --dev, ruff format --check, ruff check, mypy . and pytest collection, on both py3.9 and py3.13; actual test execution is delegated to each PR's own CI run.

2026-09-02 (addendum) — CI is red on `main`-equivalent content, for two reasons unrelated to dependencies

Both #10 and #11 came back red. Neither failure is caused by a dependency bump; both would fail on unmodified main. Full evidence in the triage comments on #10 and #11. Summary, because both need a maintainer and neither can be fixed by a security bundle:

A. `LangChain Unit Tests` — the Vectorize API returns HTTP 402 to CI

vectorize_client.exceptions.ApiException: (402)
Reason: Payment Required
{"success":false,"error":"Upgrade Required",
 "message":"API access is available on paid plans only. Please upgrade to use this endpoint.",
 "code":"UPGRADE_REQUIRED"}

Raised in the session-scoped fixture of tests/test_retrievers.py (ERROR at setup), on all five matrix legs (3.9-3.13). A 402 rather than a 401 means VECTORIZE_TOKEN authenticated fine and was rejected on plan/billing — the account behind the CI secret has lost API access.

Consequence: this workflow currently cannot pass on any branch, so it provides no signal on dependency changes. Restoring API access on that account is a prerequisite for trusting any future sweep's CI result here.

B. `Lint LangChain` — `lint.yml` ignores its own matrix and installs Python 3.14

.github/workflows/lint.yml declares matrix.python-version: ['3.9', '3.13'] but configures actions/setup-python with python-version-file: "langchain/pyproject.toml" instead of ${{ matrix.python-version }}. setup-python resolves requires-python = ">=3.9" to the newest interpreter present and logs Successfully set up CPython (3.14.7) — so both matrix legs run 3.14. pydantic-core 2.27.2 ships no cp314 wheel, uv falls back to a maturin/pyo3 source build, and it fails:

PYO3_ENVIRONMENT_SIGNATURE="cpython-3.14-64bit"
Error: command ['maturin', 'pep517', 'build-wheel', ...] returned non-zero exit status 1
hint: `pydantic-core` (v2.27.2) was included because `langchain-vectorize` (v0.0.3)
      depends on `vectorize-client` (v0.4.0) which depends on `pydantic` (v2.10.6)

This is environment drift — the repo last ran CI on 2025-09-01, before 3.14 reached the runners. pydantic 2.10.6 / pydantic-core 2.27.2 are unchanged from main in both PRs.

Two independent fixes, deliberately not bundled into a security PR:

Use python-version: ${{ matrix.python-version }} in lint.yml so the matrix is honoured (this alone makes lint green again).
Bump pydantic / pydantic-core to a release with cp314 wheels, so the repo works on current interpreters at all.

Neither package carries a security advisory, so mixing them into a security bundle would violate the sweep's own rule against combining unrelated changes.

2026-09-05 — Dependabot is scanning now; the backlog is down to one code fix and two environment problems

The "enable Dependabot alerts" ask at the top of this issue is done

GET /repos/vectorize-io/integrations-python/dependabot/alerts?state=open now returns 11 alerts instead of the empty array recorded on 2026-09-02. Advisories in this repo finally have #NNN numbers, so future runs can dedupe on alert numbers here and not only on GHSA ids. The opening paragraph of this issue is stale in that respect.

All 11 land on the single manifest langchain/uv.lock, so there is exactly one bundle target, as before.

Every one of the 11 is already fixed by #14 — no new PR was opened

#14 (security/drop-py39) raises requires-python to >=3.10, which is precisely the "Proposed fix: drop Python 3.9" recommended in this issue. Confirmed by resolving both lockfiles rather than trusting the PR body, which predates the alerts and lists only four GHSAs:

alert	package	advisory	`main` py3.9 leg	#14
#11	urllib3	GHSA-qccp-gfcp-xxvc	2.6.3	2.7.0
#12	urllib3	GHSA-mf9v-mfxr-j63j	2.6.3	2.7.0
#13	langsmith	GHSA-3644-q5cj-c5c7	0.4.37	0.12.1
#14	langsmith	GHSA-f4xh-w4cj-qxq8	0.4.37	0.12.1
#15	langsmith	GHSA-v34v-rq6j-cj6p	0.4.37	0.12.1
#9	langsmith	GHSA-rr7j-v2q5-chgv	0.4.37	0.12.1
#3	langchain-core	GHSA-2g6r-c272-w58r	0.3.86	1.6.1
#6	langchain-core	GHSA-qh6h-p6c9-ff54	0.3.86	1.6.1
#4	orjson	GHSA-hx9q-6w63-j58v	3.11.5	3.12.0
#5	requests	GHSA-gc5v-m9x4-r6x2	2.32.5	2.34.2
#8	pytest (dev)	GHSA-6w46-j5rx-g56g	8.4.2	9.1.1

Both self-inflicted regressions this issue accepted knowingly on 2026-09-02 — urllib3 landing on 2.6.3 (GHSA-mf9v-mfxr-j63j) and langsmith landing on 0.4.37 (GHSA-v34v-rq6j-cj6p) — are undone by the collapse. The residual table in the 2026-09-02 entry above goes to zero. No alert was dismissed; none is unreachable, they are all genuinely fixed by the merge.

New backlog item: #14 cannot pass lint as it stands

Not an environment failure, and not a reason to re-bundle — a two-line source fix that #14 needs and does not have.

Repo: vectorize-io/integrations-python
Branch: security/drop-py39 (security: require Python 3.10+, dropping a vulnerable resolution branch #14)
Step: uv run ruff check (the Lint LangChain job's third step)

Signature:

langchain_vectorize/retrievers.py:112:19: UP045 [*] Use `X | None` for type annotations
langchain_vectorize/retrievers.py:114:18: UP045 [*] Use `X | None` for type annotations
Found 2 errors.

Control: a main worktree on the same machine, same ruff 0.12.8 — exit 0, All checks passed!. So this is change-correlated, unlike the 402 and the 3.14 drift.
Cause: [tool.ruff] sets no target-version, so ruff infers it from requires-python. >=3.9 → >=3.10 makes PEP 604 unions legal and turns UP045 on. The two Optional[str] fields on VectorizeRetriever were compliant before the bump and are violations after it.
Fix: exactly what ruff check --fix emits — drop Optional from the typing import, organization: str | None = None, pipeline_id: str | None = None. Safe under pydantic because the module already carries from __future__ import annotations.
Verified with that patch applied in a worktree (not pushed): uv lock --check, uv sync --dev, ruff format --check, ruff check, mypy ., pytest --collect-only all clean. Left for a maintainer because it changes a published package's public annotations.

Full detail posted as a comment on #14.

Unchanged, still needs a maintainer

api.vectorize.io returns HTTP 402 UPGRADE_REQUIRED to CI, failing LangChain Unit Tests at fixture setup on every leg and every branch. Same signature seen on vectorize-clients two days apart, so it is the account/plan, not this repo. Until it is restored, LangChain Unit Tests gives no signal on any dependency change here.
lint.yml ignores its own matrix. It declares ['3.9', '3.13'] but passes python-version-file: "langchain/pyproject.toml" to setup-python, so both legs resolve to the newest interpreter on the runner (CPython 3.14.7), and pydantic-core 2.27.2 has no cp314 wheel. security: require Python 3.10+, dropping a vulnerable resolution branch #14 did not touch lint.yml, so its stale '3.9' entry now also contradicts requires-python = ">=3.10". Fix is python-version: ${{ matrix.python-version }}, plus a pydantic bump if 3.14 is wanted. Neither package carries an advisory, so this stays out of security bundles.

Local verification note (unchanged)

langchain/tests/test_retrievers.py is a live integration suite despite the job name — its session fixture needs VECTORIZE_TOKEN and hits the real API. Sweep verification here remains uv lock --check, uv sync --dev, ruff format --check, ruff check, mypy . and pytest collection only.

_{Automated daily security sweep, 2026-09-05. Nothing merged, nothing dismissed, no PR opened — the queue was already covered by #14.}

2026-09-14

No PR opened, nothing dismissed, nothing merged. Open alerts went 11 -> 17, but the queue is still fully covered by #14, so re-bundling would only have stacked a second PR on the same lockfile.

The six new alerts are already covered by #14 — without touching it

httpx2 / httpcore2 advisories landed 2026-09-08, four days after #14 was last updated (2026-09-06). They are covered anyway, for the same structural reason as the original eleven: they only ever existed on the lower resolution leg, and #14 deletes that leg.

alert	package	advisory	patched	`main` legs	#14
#16	httpx2	GHSA-7mj9-2mp8-4m2p	2.10.0	2.6.0, 2.12.0	2.12.0
#17	httpx2	GHSA-f2fp-rgf2-35cp	2.10.0	2.6.0, 2.12.0	2.12.0
#18	httpcore2	GHSA-7mj9-2mp8-4m2p	2.10.0	2.6.0, 2.12.0	2.12.0
#19	httpx2	GHSA-h4x7-gw46-3wm6	2.11.0	2.6.0, 2.12.0	2.12.0
#20	httpx2	GHSA-pf96-p4fj-6566	2.11.0	2.6.0, 2.12.0	2.12.0
#21	httpx2	GHSA-8xx6-hgc6-gc2m	2.12.0	2.6.0, 2.12.0	2.12.0

On main these two packages fork at python_full_version == '3.10.*' (2.6.0) vs >= '3.11' (2.12.0). On security/drop-py39 each is a single unforked entry at 2.12.0, so there is no vulnerable resolution left to alert on.

Resolved from both lockfiles rather than from #14's body, which predates all seventeen alerts and names only four GHSAs. Coverage is 17/17. Merging #14 closes the entire queue.

security/drop-py39 is based on current main (4a9c777) with no intervening commits, so it needs no rebase or re-lock.

Still blocking #14 — both unchanged, neither caused by a dependency bump

HTTP 402 UPGRADE_REQUIRED — still present. LangChain Unit Tests fails at fixture setup on every leg:
```
vectorize_client.exceptions.ApiException: (402)
{"success":false,"error":"Upgrade Required",
 "message":"API access is available on paid plans only. ...","code":"UPGRADE_REQUIRED"}
POST /v1/org/***/connectors/sources -> 402
```
Install the project passes on all four legs; only the live-API step fails. Both tests in the suite are live-API, so this job gives no signal on any dependency change here. Same signature on vectorize-clients, so it is the account/plan, not this repo.
lint.yml 3.14 drift — pre-existing on main, not change-correlated. Both lint legs fail at Install the project (step 6); ruff format, ruff check and mypy never run. The 2026-09-05 entry above predicted this; confirming it is now what actually fires, and that it is not attributable to security: require Python 3.10+, dropping a vulnerable resolution branch #14:
```
Successfully set up CPython (3.14.7)
x Failed to build `pydantic-core==2.27.2`
  error: the configured Python interpreter version (3.14) is newer than
         PyO3's maximum supported version (3.13)   [pyo3 0.22.6]
```
Byte-identical on main (run 33920711195, requires-python = ">=3.9") and on security: require Python 3.10+, dropping a vulnerable resolution branch #14 (run 33920963630, ">=3.10"), and identical across both the '3.9' and '3.13' matrix legs — because python-version-file: "langchain/pyproject.toml" overrides the matrix and both legs get the runner's newest interpreter. Fix is still python-version: ${{ matrix.python-version }} plus a pydantic bump if 3.14 is wanted; neither package carries an advisory.

Note this now masks the UP045 item from 2026-09-05 — ruff check is skipped, so that two-line fix is still needed and still unverifiable in CI until the interpreter pin is fixed.

Local verification on the #14 worktree: uv lock --check and uv sync --dev both exit 0 on uv 0.11.18 / CPython 3.12.13.

_{Automated daily security sweep, 2026-09-14. Nothing merged, nothing dismissed, no PR opened — the queue was already covered by #14.}

2026-09-20

No PR opened, nothing dismissed, nothing merged. Open alerts went 17 -> 19. Coverage re-derived from scratch against #14's head lock (45373d8) rather than assumed from the 2026-09-14 entry: 19/19 still covered. Merging #14 closes the entire queue, including the new critical.

The two new alerts are `anyio`, and one of them is critical

alert	package	advisory	severity	patched	`main` legs	#14
#22	anyio	GHSA-5p39-cfhj-2xmp	medium	4.14.2	4.8.0, 4.15.0	4.15.0
#23	anyio	GHSA-82r6-8w77-94w6	critical	4.14.2	4.8.0, 4.15.0	4.15.0

Both opened 2026-09-19, two weeks after #14 was last pushed. Covered for the same structural reason as the previous seventeen: anyio 4.8.0 exists only on the lower resolution leg, and #14 deletes that leg. This is the first critical advisory to land in this queue, and it is reachable today on main for anyone installing under the lower leg.

Full re-derivation, all 19

Resolved by parsing [[package]] blocks in both lockfiles and testing each version against the advisory's own vulnerable_version_range — not read off #14's body, which predates all nineteen alerts and names only four GHSAs.

main (4a9c777, requires-python = ">=3.9") forks 12 packages. security/drop-py39 forks exactly one — websockets (16.1.1 / 17.1) — which carries no advisory.

alert	package	advisory	`main` vulnerable leg	#14
#3	langchain-core	GHSA-2g6r-c272-w58r	0.3.86	1.6.1
#4	orjson	GHSA-hx9q-6w63-j58v	3.11.5	3.12.0
#5	requests	GHSA-gc5v-m9x4-r6x2	2.32.5	2.34.2
#6	langchain-core	GHSA-qh6h-p6c9-ff54	0.3.86	1.6.1
#8	pytest (dev)	GHSA-6w46-j5rx-g56g	8.4.2	9.1.1
#9	langsmith	GHSA-rr7j-v2q5-chgv	0.4.37	0.12.1
#11	urllib3	GHSA-qccp-gfcp-xxvc	2.6.3	2.7.0
#12	urllib3	GHSA-mf9v-mfxr-j63j	2.6.3	2.7.0
#13	langsmith	GHSA-3644-q5cj-c5c7	0.4.37	0.12.1
#14	langsmith	GHSA-f4xh-w4cj-qxq8	0.4.37	0.12.1
#15	langsmith	GHSA-v34v-rq6j-cj6p	0.4.37	0.12.1
#16	httpx2	GHSA-7mj9-2mp8-4m2p	2.6.0	2.12.0
#17	httpx2	GHSA-f2fp-rgf2-35cp	2.6.0	2.12.0
#18	httpcore2	GHSA-7mj9-2mp8-4m2p	2.6.0	2.12.0
#19	httpx2	GHSA-h4x7-gw46-3wm6	2.6.0	2.12.0
#20	httpx2	GHSA-pf96-p4fj-6566	2.6.0	2.12.0
#21	httpx2	GHSA-8xx6-hgc6-gc2m	2.6.0	2.12.0
#22	anyio	GHSA-5p39-cfhj-2xmp	4.8.0	4.15.0
#23	anyio	GHSA-82r6-8w77-94w6	4.8.0	4.15.0

All nineteen land on the single manifest langchain/uv.lock, so there is exactly one bundle target and #14 already owns it (+62/-628 on that file). A second PR would collide on the same lockfile, so none was opened.

No alert is dismissable — none is unreachable. They are all real resolutions that a pip install under the lower leg would select, and the CI matrix tested 3.9 until #14 changed it.

#14 needs no rebase

security/drop-py39 is still based on current main (4a9c777) with no intervening commits. mergeable: MERGEABLE, review state APPROVED since 2026-09-14.

Local verification on a worktree at 45373d8, uv 0.11.18 / CPython 3.12.13:

uv lock --check   -> Resolved 51 packages, exit 0
uv sync --dev     -> exit 0

Still blocking #14 — both unchanged, neither caused by a dependency bump

#14 is 16 days old, approved, and cannot go green as the repo is configured. Its last CI run is from 2026-09-04 (33920963576 / 33920963630); nothing has re-run since. Both failures reproduce on unmodified main (Python lint and Python tests are red at 4a9c777, the current HEAD), so neither is change-correlated:

HTTP 402 UPGRADE_REQUIRED — LangChain Unit Tests fails at fixture setup on every leg:

vectorize_client.exceptions.ApiException: (402)
{"success":false,"error":"Upgrade Required",
 "message":"API access is available on paid plans only. ...","code":"UPGRADE_REQUIRED"}
POST /v1/org/***/connectors/sources -> 402

Both tests in the suite are live-API, so this job gives no signal on any dependency change here.

lint.yml 3.14 drift — both lint legs still fail at Install the project:
```
Using CPython 3.14.7 interpreter at: /opt/hostedtoolcache/Python/3.14.7/x64/bin/python3
x Failed to build `pydantic-core==2.27.2`
hint: `pydantic-core` (v2.27.2) was included because `langchain-vectorize` (v0.0.3)
      depends on `vectorize-client` (v0.4.0) which depends on `pydantic` (v2.10.6)
```
.github/workflows/lint.yml still declares matrix.python-version: ['3.9', '3.13'] while passing python-version-file: "langchain/pyproject.toml" to setup-python, so both legs resolve to the runner's newest interpreter regardless of the matrix. security: require Python 3.10+, dropping a vulnerable resolution branch #14 updated the matrix in python_test.yml but did not touch lint.yml (confirmed: empty diff for that file between main and security/drop-py39), so its stale '3.9' entry also contradicts requires-python = ">=3.10".

Fix remains python-version: ${{ matrix.python-version }}, plus a pydantic bump if 3.14 is wanted. Neither package carries an advisory, so this stays out of security bundles.

This continues to mask the UP045 item from 2026-09-05 — ruff check never runs, so that two-line fix is still needed and still unverifiable in CI.

Priority raised

Relabelled #14 p1 -> p0 by the sweep, matching that label's own definition ("Critical severity - remediate within 7 days"), because alert #23 is the queue's first critical and #14 is its only remedy. Revert if that is not wanted.

What a maintainer needs to do

Nothing in this repo's dependency graph is blocking. The 19 open alerts are held open by review/infra, not by a missing fix:

Merge security: require Python 3.10+, dropping a vulnerable resolution branch #14 (approved, no conflicts, lock verified clean locally) — closes all 19.
Restore API access on the account behind VECTORIZE_TOKEN, or mock the suite, so LangChain Unit Tests gives signal again.
Fix lint.yml's interpreter pin.

_{Automated daily security sweep, 2026-09-20. Nothing merged, nothing dismissed, no PR opened — the queue was already covered by #14.}

Navigation Menu

Repository navigation

Daily security sweep — backlog #12

Context: Dependabot is not scanning this repo

2026-09-02

Root cause of everything below: `requires-python = ">=3.9"`

Two regressions introduced on the py3.9 leg (accepted knowingly)

Note on local verification

2026-09-02 (addendum) — CI is red on `main`-equivalent content, for two reasons unrelated to dependencies

A. `LangChain Unit Tests` — the Vectorize API returns HTTP 402 to CI

B. `Lint LangChain` — `lint.yml` ignores its own matrix and installs Python 3.14

2026-09-05 — Dependabot is scanning now; the backlog is down to one code fix and two environment problems

The "enable Dependabot alerts" ask at the top of this issue is done

Every one of the 11 is already fixed by #14 — no new PR was opened

New backlog item: #14 cannot pass lint as it stands

Unchanged, still needs a maintainer

Local verification note (unchanged)

2026-09-14

The six new alerts are already covered by #14 — without touching it

Still blocking #14 — both unchanged, neither caused by a dependency bump

2026-09-20

The two new alerts are `anyio`, and one of them is critical

Full re-derivation, all 19

#14 needs no rebase

Still blocking #14 — both unchanged, neither caused by a dependency bump

Priority raised

What a maintainer needs to do

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Daily security sweep — backlog #12

Description

Context: Dependabot is not scanning this repo

2026-09-02

Root cause of everything below: requires-python = ">=3.9"

Two regressions introduced on the py3.9 leg (accepted knowingly)

Note on local verification

Activity

benfrank241 commented on Sep 2, 2026

2026-09-02 (addendum) — CI is red on main-equivalent content, for two reasons unrelated to dependencies

A. LangChain Unit Tests — the Vectorize API returns HTTP 402 to CI

B. Lint LangChain — lint.yml ignores its own matrix and installs Python 3.14

benfrank241 commented on Sep 5, 2026

2026-09-05 — Dependabot is scanning now; the backlog is down to one code fix and two environment problems

The "enable Dependabot alerts" ask at the top of this issue is done

Every one of the 11 is already fixed by #14 — no new PR was opened

New backlog item: #14 cannot pass lint as it stands

Unchanged, still needs a maintainer

Local verification note (unchanged)

benfrank241 commented on Sep 14, 2026

2026-09-14

The six new alerts are already covered by #14 — without touching it

Still blocking #14 — both unchanged, neither caused by a dependency bump

benfrank241 commented on Sep 20, 2026

2026-09-20

The two new alerts are anyio, and one of them is critical

Full re-derivation, all 19

#14 needs no rebase

Still blocking #14 — both unchanged, neither caused by a dependency bump

Priority raised

What a maintainer needs to do

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Root cause of everything below: `requires-python = ">=3.9"`

2026-09-02 (addendum) — CI is red on `main`-equivalent content, for two reasons unrelated to dependencies

A. `LangChain Unit Tests` — the Vectorize API returns HTTP 402 to CI

B. `Lint LangChain` — `lint.yml` ignores its own matrix and installs Python 3.14

The two new alerts are `anyio`, and one of them is critical