PHANTOM
🇮🇳 IN
Skip to content

redis connection leak used by Dify #32638

@liuyang3333

Description

@liuyang3333

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, 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.

Dify version

1.10.1.fix

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Dify works fine, but redis keeps growing client connections.
Client connections are more worker services and api services, most workers, use db1 this library, this library should be celery in use.

Image

10.72.197.245 This IP address has increased by nearly 50 links in an hour.

Image

✔️ Expected Behavior

redis connection normal release

❌ Actual Behavior

First, I located from the number of connections to the Worker service connection, the service uses db1 (the library used by Celery in Dify), thus locking Celery; combined with Flask-SQLAlchemy in Celery tasks will not automatically close the session, Celery also does not have "task end teardown", confirm that Dify in Celery tasks does not explicitly close db.session, resulting in connection not returned, resulting in leakage, is Dify application logic problem. The page is not stuck, the workflow is executed normally, but the number of Redis client connections is too long, which can also indicate that "the connection is slowly leaking but the connection pool is not full", rather than the queue backlog.

Metadata

Metadata

Assignees

No one assigned

    Labels

    🐞 bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions