how to avoid session closed then visit

[asukaminato0721]

The Account object returned by get_account_by_email_with_case_fallback is accessed after the database session has already closed.

Often meet this, in rust we have life scope to avoid this.

But how to do this in python?

@dosu @gemini-code-assist any idea?

[dosubot]

This is a known DetachedInstanceError caused by the session management refactoring in PR #33966 (shipped with v1.13.3). The Account object's attributes get expired once the with session.begin() block exits, so any subsequent access raises the error [1].

In Python/SQLAlchemy, the equivalent of Rust's lifetime/scope management is handled through expire_on_commit. By default, SQLAlchemy expires all object attributes after a commit, so accessing them outside the session scope triggers DetachedInstanceError.

Fix: Use expire_on_commit=False when creating the session:

with sessionmaker(db.engine, expire_on_commit=False).begin() as session:
    account = AccountService.get_account_by_email_with_case_fallback(args.email, session=session)

# account attributes are still accessible here
token = AccountService.send_reset_password_email(account=account, ...)

Other common patterns to avoid this in Python/SQLAlchemy:

1. Keep all access within the session scope — move the code that uses the object inside the with block
2. Eagerly load the attributes you need (e.g., session.query(...).options(joinedload(...))) so they're loaded into memory before the session closes
3. Copy needed values into plain variables/dicts before leaving the session scope

This has been a recurring issue in Dify — the same fix pattern applies to similar errors reported in other endpoints [1]. A PR fixing this specific instance in forgot_password.py would be welcome.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[asukaminato0721]

@dosu so it's like Box::leak in rust?

[dosubot]

Not quite — Box::leak deliberately leaks memory by giving you a &'static reference, meaning the data lives forever and is never freed. That's usually a last resort.

expire_on_commit=False is closer to cloning the data out of a borrowed scope before the borrow ends. The SQLAlchemy object still gets garbage-collected normally — you're just telling SQLAlchemy "don't invalidate the cached attribute values when the transaction commits." The data is already loaded in memory; you're opting out of the lazy-expiration behavior, not leaking anything.

A rough Rust analogy:

SQLAlchemy pattern	Rust equivalent
Default (expire_on_commit=True)	Borrowing from a scope — data invalidated when scope ends
expire_on_commit=False	.clone() before the scope ends — you own a copy
Eagerly load + copy to dict	let val = borrowed.field.clone(); — extract what you need
Box::leak	No real equivalent here — nothing is intentionally leaked

So think of it more as .clone() than Box::leak. The object holds a snapshot of the data in memory rather than maintaining a live reference back to the database session.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[asukaminato0721]

when I meet nest sessionmaker, how to solve it ? @dosu

[dosubot]

Dify avoids nested sessionmaker calls entirely. There are two main patterns used:

1. Pass the session down — the parent creates the session and passes it to child functions:

with sessionmaker(db.engine).begin() as session:
    account = AccountService.get_account_by_email_with_case_fallback(email, session=session)
    # pass the same session to the next call
    AccountService.send_reset_password_email(account=account, session=session)

This is the most common pattern in the codebase [1] [2]. All functions share one transaction — if anything fails, everything rolls back together.

2. Sequential (not nested) sessions — when you truly need separate transactions, use them one after another, not inside each other:

# Transaction 1
with sessionmaker(db.engine).begin() as session:
    data = session.scalar(select(Model).where(...))

# Transaction 2 (separate, after the first one closed)
with sessionmaker(db.engine).begin() as session:
    session.add(NewModel(value=data))

[3]

Key pitfall to watch for: If a child function calls session.commit() while inside an outer sessionmaker().begin() block, you'll get an InvalidRequestError: Can't operate on closed transaction. The fix is to use session.flush() instead of session.commit() inside nested service calls — flush() sends the SQL to the database without closing the transaction, and the outer begin() context manager handles the final commit [4].

In short: don't nest sessions — share them by passing them as parameters, and use flush() instead of commit() in inner functions.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[asukaminato0721]

@dosu final problem: how can I avoid nest them by accidentally? Like some type checker.

Since now we use db.session, and convert it may introduce some problems.

[dosubot]

Currently there's no static analysis in Dify to catch accidental session nesting — Ruff, MyPy, and import-linter are all configured but none target session misuse [1] [2].

Here are a few practical approaches you could adopt:

1. Custom Ruff/flake8 rule (lint-time) — Write a plugin or use Ruff's custom rules / Semgrep to flag sessionmaker(...) calls inside functions that already accept a session parameter:

# semgrep rule example
rules:
  - id: no-nested-sessionmaker
    pattern: |
      def $FUNC(..., session=..., ...):
          ...
          with sessionmaker(...).begin() as $S:
              ...
    message: "Don't create a new session inside a function that already receives one"
    severity: WARNING

2. Runtime guard (debug-time) — Use a contextvars.ContextVar to track whether a session is already active, and raise on nesting:

import contextvars

_active_session: contextvars.ContextVar[bool] = contextvars.ContextVar("_active_session", default=False)

@contextlib.contextmanager
def safe_session(engine):
    if _active_session.get():
        raise RuntimeError("Nested session detected! Pass the existing session instead.")
    _active_session.set(True)
    try:
        with sessionmaker(engine).begin() as session:
            yield session
    finally:
        _active_session.set(False)

This gives you a Rust-like "borrow checker at runtime" — it'll loudly fail in dev/tests if someone accidentally nests sessions.

3. Leverage import-linter (already in the project) — Dify already uses import-linter for package structure validation. You could add contracts to restrict db.session imports to controller modules only, which aligns with the existing architectural guideline that db should be avoided outside controllers [3]:

[importlinter:contract:no-db-session-outside-controllers]
name = db.session only in controllers
type = forbidden
source_modules = api.services, api.core
forbidden_modules = extensions.ext_database

4. Type-level enforcement — Make the session a required parameter (no default) in service functions. MyPy will then catch any caller that forgets to pass it:

# Force callers to explicitly pass a session — no optional, no default
def get_account(email: str, session: Session) -> Account:
    ...

Of these, the runtime ContextVar guard (#2) gives you the closest thing to Rust's compile-time borrow checking — it catches nesting immediately during development and testing. Combining it with import-linter rules (#3) to restrict db.session usage would cover both the nesting and the legacy db.session migration concerns.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[asukaminato0721]

@dosu I guess use test container can be a solution as for now...

also raise it facebook/pyrefly#3092

[dosubot]

Yeah, testcontainers would definitely help catch these at test time — spinning up a real DB in tests means DetachedInstanceError and nested session issues surface immediately rather than only in production.

And nice, filing that on Pyrefly is a great idea — cross-function session nesting detection at the type-checker level would be the real Python equivalent of Rust's borrow checker for this pattern. The tricky part will be tracking session lifetimes across call boundaries, but if any tool can do it, a Rust-based type checker like Pyrefly seems like a good candidate. Hopefully it gets some traction! 🤞

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}