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.13.3 (affects all versions since 1.10.0)

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. Deploy Dify (any version ≥ 1.10.0) with default configuration — ENABLE_TRIGGER_PROVIDER_REFRESH_TASK defaults to true
2. Start the Celery worker using the standard Docker entrypoint (api/docker/entrypoint.sh)
3. Wait several days or weeks
4. Check Redis DB 1 (Celery broker database):

   redis-cli -n 1 LLEN trigger_refresh_publisher

5. Observe a continuously growing count

✔️ Expected Behavior

The trigger_provider_refresh Celery Beat task (defined in api/schedule/trigger_provider_refresh_task.py:52 with queue="trigger_refresh_publisher") should be consumed by workers. The trigger_refresh_publisher queue should be listed in DEFAULT_QUEUES in api/docker/entrypoint.sh, alongside trigger_refresh_executor which is already correctly registered.

❌ Actual Behavior

trigger_refresh_publisher is not listed in DEFAULT_QUEUES in api/docker/entrypoint.sh (lines 38 and 41 as of v1.13.3), so no worker consumes this queue. Celery Beat enqueues a task every TRIGGER_PROVIDER_REFRESH_INTERVAL minutes (default: 1), and all messages accumulate indefinitely in Redis.

Observed impact on a production instance running for ~3 months:

• 285,000+ Celery messages accumulated in the Redis list key trigger_refresh_publisher (DB 1)
• ~410 MB of Redis memory consumed (94% of total used_memory)
• Memory grows at ~5 MB/day with no upper bound
• The key has no TTL, and under volatile-lru policy it is not eligible for eviction

Additionally, because trigger_provider_refresh never executes, TriggerSubscription credential and subscription pre-renewal is silently non-functional.

Root Cause

PR #27644 (feat: introduce trigger functionality, merged 2025-11-12) introduced two queues:

The follow-up PR #28179 (merged 2025-11-13) updated .devcontainer/post_create_command.sh but also only added trigger_refresh_executor, not trigger_refresh_publisher.

Verified on upstream source: both v1.10.0 and v1.13.3 api/docker/entrypoint.sh contain trigger_refresh_executor but not trigger_refresh_publisher.

Suggested Fix

Add trigger_refresh_publisher to DEFAULT_QUEUES in api/docker/entrypoint.sh (both Cloud and Community editions):

# Line 38 (Cloud)
- DEFAULT_QUEUES="...,trigger_refresh_executor,retention,..."
+ DEFAULT_QUEUES="...,trigger_refresh_publisher,trigger_refresh_executor,retention,..."

# Line 41 (Community / Self-hosted)
- DEFAULT_QUEUES="...,trigger_refresh_executor,retention,..."
+ DEFAULT_QUEUES="...,trigger_refresh_publisher,trigger_refresh_executor,retention,..."

Also consider adding trigger_refresh_publisher to .devcontainer/post_create_command.sh (same omission in #28179).

Additional Notes

• There may be other queues with the same pattern of "declared in task decorator but missing from DEFAULT_QUEUES". For example, monitor (defined in schedule/queue_monitor_task.py) appears to have a Beat schedule but is not in DEFAULT_QUEUES.
• A CI check that validates all @app.celery.task(queue=...) / @shared_task(queue=...) queues are present in DEFAULT_QUEUES would prevent similar regressions.
• Users who have already accumulated messages can safely purge them: redis-cli -n 1 UNLINK trigger_refresh_publisher (after stopping Beat to prevent re-accumulation).