langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Redis cache key collision in trigger nodes causes data corruption across apps #20437

New Issue
Closed
opened 2026-02-21 20:07:27 -05:00 by yindo · 1 comment
yindo commented 2026-02-21 20:07:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @17hz on GitHub (Nov 20, 2025).

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, including closed ones
  • I confirm that I am using English to submit this report
  • Please do not modify this template and fill in all the required fields

Dify version

Current main branch

Cloud or Self Hosted

  • Cloud
  • Self Hosted (Docker)
  • Self Hosted (Source)

Steps to reproduce

  1. Create a workflow with a webhook trigger node
  2. Duplicate this workflow to create a copy
  3. Open the duplicated workflow
  4. Observe that the webhook URL is not found or shows an error

✔️ Expected Behavior

When duplicating a workflow with a webhook trigger:

  • The duplicated workflow should have its own isolated cache entries
  • Each workflow's trigger nodes should use cache keys that include both app_id and node_id
  • The webhook URL should be properly generated and accessible for the duplicated workflow
  • Cache key format: {CACHE_KEY}:{app_id}:{node_id}

❌ Actual Behavior

The current implementation uses only node_id as the Redis cache key:

Cache key format: {CACHE_KEY}:{node_id}

When duplicating a workflow, the duplicated workflow's trigger node has the same node_id as the original, causing cache key collisions. This leads to:

  • Shared cache entries between the original and duplicated workflows
  • The duplicated workflow cannot find its webhook URL
  • Data corruption when one workflow's cache overwrites another's

Root Cause:
The cache key lacks app_id, so trigger nodes with the same node_id across different applications share the same Redis cache entry.

Affected services:

  • api/services/trigger/trigger_service.py - Plugin trigger node cache operations
  • api/services/trigger/webhook_service.py - Webhook trigger node cache operations
Originally created by @17hz on GitHub (Nov 20, 2025). ## Self Checks - [x] I have read the Contributing Guide and Language Policy - [x] This is only for bug report, if you would like to ask a question, please head to Discussions - [x] I have searched for existing issues, including closed ones - [x] I confirm that I am using English to submit this report - [x] Please do not modify this template and fill in all the required fields ## Dify version Current main branch ## Cloud or Self Hosted - Cloud - Self Hosted (Docker) - Self Hosted (Source) ## Steps to reproduce 1. Create a workflow with a webhook trigger node 2. Duplicate this workflow to create a copy 3. Open the duplicated workflow 4. Observe that the webhook URL is not found or shows an error ## ✔️ Expected Behavior When duplicating a workflow with a webhook trigger: - The duplicated workflow should have its own isolated cache entries - Each workflow's trigger nodes should use cache keys that include both `app_id` and `node_id` - The webhook URL should be properly generated and accessible for the duplicated workflow - Cache key format: `{CACHE_KEY}:{app_id}:{node_id}` ## ❌ Actual Behavior The current implementation uses only `node_id` as the Redis cache key: ``` Cache key format: {CACHE_KEY}:{node_id} ``` When duplicating a workflow, the duplicated workflow's trigger node has the same `node_id` as the original, causing cache key collisions. This leads to: - Shared cache entries between the original and duplicated workflows - The duplicated workflow cannot find its webhook URL - Data corruption when one workflow's cache overwrites another's **Root Cause:** The cache key lacks `app_id`, so trigger nodes with the same `node_id` across different applications share the same Redis cache entry. **Affected services:** - `api/services/trigger/trigger_service.py` - Plugin trigger node cache operations - `api/services/trigger/webhook_service.py` - Webhook trigger node cache operations
yindo added the 🐞 bug label 2026-02-21 20:07:27 -05:00
yindo closed this issue 2026-02-21 20:07:27 -05:00
yindo commented 2026-02-21 20:07:27 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 20, 2025):

You’re correct about the root cause: both api/services/trigger/trigger_service.py and api/services/trigger/webhook_service.py currently use Redis cache keys that only include node_id, like {CACHE_KEY}:{node_id}. This leads to collisions and data corruption when workflows are duplicated across apps, since node IDs can be reused.

The fix is to update all cache operations (get/set/delete) in these files to use a key format that includes both app_id and node_id, for example: {CACHE_KEY}:{app_id}:{node_id}. This ensures cache isolation between apps and prevents overwriting or sharing cache entries.

There’s already an open pull request that implements this change and updates all relevant Redis operations to use the new format, which should resolve the issue and prevent future collisions. You can review the proposed changes and details here: PR: fix add app_id to Redis cache keys for trigger nodes.

No migration steps for existing cache entries are mentioned, but since cache is typically ephemeral, updating the key format should be safe. If you have workflows relying on cached trigger data, you may want to clear old cache entries after deploying the fix.

Let me know if you need help locating the exact lines to update or want a code snippet for the new cache key pattern.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 20, 2025): <!-- Answer --> You’re correct about the root cause: both `api/services/trigger/trigger_service.py` and `api/services/trigger/webhook_service.py` currently use Redis cache keys that only include `node_id`, like `{CACHE_KEY}:{node_id}`. This leads to collisions and data corruption when workflows are duplicated across apps, since node IDs can be reused. The fix is to update all cache operations (get/set/delete) in these files to use a key format that includes both `app_id` and `node_id`, for example: `{CACHE_KEY}:{app_id}:{node_id}`. This ensures cache isolation between apps and prevents overwriting or sharing cache entries. There’s already an open pull request that implements this change and updates all relevant Redis operations to use the new format, which should resolve the issue and prevent future collisions. You can review the proposed changes and details here: [PR: fix add app_id to Redis cache keys for trigger nodes](https://github.com/langgenius/dify/pull/28243). No migration steps for existing cache entries are mentioned, but since cache is typically ephemeral, updating the key format should be safe. If you have workflows relying on cached trigger data, you may want to clear old cache entries after deploying the fix. Let me know if you need help locating the exact lines to update or want a code snippet for the new cache key pattern. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/75e2101c-b68e-4125-9b30-60c163af30e4?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28440)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#20437
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?