Skip to content

[fastapi] Fix false positive for pre-assigned Depends variables (FAST003)#26354

Open
kpeis695 wants to merge 1 commit into
astral-sh:mainfrom
kpeis695:fix/fast003-assigned-depends-false-positive
Open

[fastapi] Fix false positive for pre-assigned Depends variables (FAST003)#26354
kpeis695 wants to merge 1 commit into
astral-sh:mainfrom
kpeis695:fix/fast003-assigned-depends-false-positive

Conversation

@kpeis695

Copy link
Copy Markdown

Summary

Fixes #17226.

When a Depends(...) call is pre-assigned to a variable and that variable is used as metadata in an Annotated annotation, FAST003 incorrectly fires:

async def find_item(item_id: int): ...

FindItem = Depends(find_item)

@app.get("/items/{item_id}")
async def get_item(item: Annotated[str, FindItem]): ...
#                                       ^^^^^^^^^
# FAST003: Parameter `item_id` appears in route path, but not in `get_item` signature

The rule scans Annotated metadata elements for literal Depends(...) calls. A pre-assigned Depends variable is a bare name — not a call expression — so depends_arguments returns None, the element is silently skipped by the filter_map, and the path parameter appears unused.

The fix treats a bare-name metadata element as Dependency::Unknown (unless it clearly resolves to a function, class, or import), which causes the check to abort conservatively rather than emitting a false positive.

Test Plan

Snapshot tests (cargo nextest run and cargo insta test).

@astral-sh-bot astral-sh-bot Bot requested a review from ntBre June 25, 2026 06:06
@MichaReiser

Copy link
Copy Markdown
Member

Can you rephrase the title please? I'm not sure what's up with installing fastapi

@kpeis695 kpeis695 changed the title [To use the fastapi command, please install "fastapi[standard]": pip install "fastapi[standard]"] Fix false positive for assigned Depends variables (FAST003) [fastapi] Fix false positive for pre-assigned Depends variables (FAST003) Jun 25, 2026
@kpeis695

Copy link
Copy Markdown
Author

Updated the title — sorry about that, the FastAPI CLI in my shell polluted the output when I created the PR.

// We can't statically resolve what it wraps, so treat it as unknown to avoid
// false positives — unless it clearly isn't a dependency (i.e. it resolves to
// something other than an assignment).
match semantic.only_binding(name).map(|id| semantic.binding(id)) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to the trouble of resolving a Name to a binding, I don't think it would take much more to get the value itself and see if it's a Depends. Is that right?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. If the binding is an Assignment, we could walk the RHS and look for a Depends(...) call. Would you want us to fully resolve what it wraps in that case, or just confirm it's a Depends and suppress if we can't trace it further? Happy to give it a shot either way.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should treat it the same way as an inline Depends.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. When the binding is an Assignment, we now walk the RHS and call depends_arguments on it. If it's a Depends call we treat it exactly like an inline one. If the RHS isn't a Depends at all we still fall back to Unknown to stay conservative.

When a `Depends(...)` call is stored in a variable and that variable is
used as metadata in `Annotated[T, AssignedDepends]`, ruff now resolves
the assignment RHS to determine which parameters the dependency covers,
treating it the same as an inline `Depends(...)`.

Previously the rule suppressed the diagnostic for all bare-name metadata
elements that resolved to an assignment, which caused false negatives
when the path parameter was genuinely missing. Now only the assignment
case where the RHS is not a `Depends` call falls back to `Unknown`.

Fixes astral-sh#17226

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@kpeis695 kpeis695 force-pushed the fix/fast003-assigned-depends-false-positive branch from 593fb48 to b0e2b83 Compare June 25, 2026 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

FAST003 false positive when path parameter is included inside a BaseModel dependency

3 participants