Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix [Refactor/Chore] use [T] instead of Any [1 pull requests, 3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#34878•Fetched 2026-04-10 03:45:38
View on GitHub
Comments
3
Participants
3
Timeline
10
Reactions
2
Author
asukaminato0721asukaminato0721
Participants
asukaminato0721asukaminato0721corevibe555corevibe555dosubot[bot]dosubot[bot]
Assignees
corevibe555corevibe555
Timeline (top)
commented ×3cross-referenced ×2mentioned ×2subscribed ×2

now dify use >= 3.12, which means we can use f[T1, T2](x: T1, y: T2) to type functions.

Root Cause

now dify use >= 3.12, which means we can use f[T1, T2](x: T1, y: T2) to type functions.

Fix Action

Fixed

PR fix notes

PR #34880: refactor(models): replace Any with precise types in Tenant and MCPToo…

Description (problem / solution / changelog)

Part of: https://github.com/langgenius/dify/issues/34878

Summary

  • Remove dead SessionT and LifespanContextT TypeVar definitions from entities.py (shadowed by inline generics on RequestContext class)
  • Replace Callable[..., Any] -> Any with Callable[..., T] -> T in MCPClientWithAuthRetry._execute_with_retry and ModelInstance._round_robin_invoke, preserving return types through wrapper functions
  • Remove stale TypeVar import tests from test_entities.py

Why this change

The TypeVar definitions in entities.py were dead code — RequestContext already uses Python 3.12 inline generic syntax [SessionT: ..., LifespanContextT], which shadows the module-level TypeVars.

_execute_with_retry and _round_robin_invoke both wrap a callable and return its result, but the Any return type erased type information for callers. Using def f[T](func: Callable[..., T]) -> T preserves the return type through the wrapper.

Changes

  • api/core/mcp/entities.py: Remove unused TypeVar definitions and TypeVar import
  • api/core/mcp/auth_client.py: Generic return type on _execute_with_retry
  • api/core/model_manager.py: Generic return type on _round_robin_invoke
  • api/tests/unit_tests/core/mcp/test_entities.py: Remove tests for deleted TypeVars

Test plan

  • ruff check passes

Changed files

  • api/core/mcp/auth_client.py (modified, +1/-1)
  • api/core/mcp/entities.py (modified, +2/-5)
  • api/core/model_manager.py (modified, +64/-92)
  • api/core/rag/rerank/rerank_model.py (modified, +23/-21)
  • api/tests/unit_tests/core/mcp/test_entities.py (modified, +0/-41)
RAW_BUFFERClick to expand / collapse

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for refactors or chores; if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Description

now dify use >= 3.12, which means we can use f[T1, T2](x: T1, y: T2) to type functions.

Motivation

easier to remove Any

Additional Context

No response

extent analysis

TL;DR

Update function type definitions to utilize the new type inference syntax available in version 3.12 and above.

Guidance

  • Review existing function definitions to identify areas where the f[T1, T2](x: T1, y: T2) syntax can be applied to improve type safety.
  • Replace Any types with explicit type parameters where possible to enhance code readability and maintainability.
  • Verify that the updated function definitions are correctly inferred by the compiler and do not introduce any new type errors.
  • Consider adding tests to ensure the correctness of the updated functions.

Example

// Before
function exampleFunc(x: any, y: any): any {
  // function body
}

// After
function exampleFunc<T1, T2>(x: T1, y: T2): [T1, T2] {
  // function body
  return [x, y];
}

Notes

The effectiveness of this update depends on the specific use cases and the existing codebase. It is essential to thoroughly review and test the changes to ensure they do not introduce any regressions.

Recommendation

Apply workaround by updating function type definitions to utilize the new syntax, as it improves type safety and code maintainability.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#model loading#dependency error#configuration error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING