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

Removing member from workspace causes tenant not found errors in worker container #21823

New Issue
Open
opened 2026-02-21 20:14:29 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 20:14:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @TamatamaAlex on GitHub (Jan 21, 2026).

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.11.4

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Removing a member who has created an app/workflow from a workspace causes traces being sent to 3rd party applications (in this case Langfuse) to cause tenant not found errors.

worker-1            | 2026-01-22 01:43:11.970 INFO [Dummy-3] [ops_trace_manager.py:355] d6eaefef1b775f798a2aa5e9744970e9 - new tracing_instance for app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9
worker-1            | 2026-01-22 01:43:11.973 INFO [Dummy-3] [ops_trace_task.py:48] d6eaefef1b775f798a2aa5e9744970e9 - Processing trace tasks success, app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9
worker-1            | 2026-01-22 01:43:11.998 INFO [Dummy-3] [trace.py:128] d6eaefef1b775f798a2aa5e9744970e9 - Task tasks.ops_trace_task.process_trace_tasks[29d475a1-394c-4023-b7fb-a19830f82b8b] succeeded in 0.7747870711609721s: None
worker-1            | 2026-01-22 01:43:13.221 INFO [MainThread] [strategy.py:161]  - Task tasks.ops_trace_task.process_trace_tasks[74318146-f9f7-4e0a-ac74-6217c93138d6] received
worker-1            | 2026-01-22 01:43:13.301 INFO [Dummy-5] [ops_trace_task.py:50] a59a267af5df5efa97a73817d829c420 - error:
worker-1            |
worker-1            |
worker-1            | Current tenant not found for account c55361b6-9877-447e-b6b4-49546d7986f3
worker-1            |
worker-1            |
worker-1            |
worker-1            |
worker-1            | 2026-01-22 01:43:13.302 INFO [Dummy-5] [ops_trace_task.py:53] a59a267af5df5efa97a73817d829c420 - Processing trace tasks failed, app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9
worker-1            | 2026-01-22 01:43:13.326 INFO [Dummy-5] [trace.py:128] a59a267af5df5efa97a73817d829c420 - Task tasks.ops_trace_task.process_trace_tasks[74318146-f9f7-4e0a-ac74-6217c93138d6] succeeded in 0.10417425213381648s: None
worker-1            | 2026-01-22 01:43:26.026 INFO [MainThread] [strategy.py:161]  - Task schedule.workflow_schedule_task.poll_workflow_schedules[0784563c-924b-45ea-ad69-7362f97123c4] received
worker-1            | 2026-01-22 01:43:26.405 INFO [Dummy-6] [trace.py:128] d6429b279648528a96121549e4da2f38 - Task schedule.workflow_schedule_task.poll_workflow_schedules[0784563c-924b-45ea-ad69-7362f97123c4] succeeded in 0.37737353704869747s: None

My best guess is that due to the 'created_by' in the PostgreSQL database remaining set to the old member's uuid, the tracing configuration has also been affected. However, I had also updated Dify from version 1.11.1 to 1.11.2 around that same timeframe. Updating to 1.11.4 has not fixed the error.

I also noticed that despite removing the member from the workspace, their login information is still present in the database under public.accounts, but the worker container can't find the tenant it appears.

I haven't tried manually changing the owner/created_by to be someone else for the app yet, but I wonder if that would fix the issue.

No errors have been found for Langfuse's container.

✔️ Expected Behavior

Observations in Langfuse had shown knowledge retrieval information, such as what knowledge was read by the app.

❌ Actual Behavior

All knowledge retrieval observations have disappeared, but the normal workflow observations are still present.

In summary:
Before updating to >=1.11.2 and before removing a member from workspace there were knowledge retrieval observations being sent to langfuse.
After updating and removing the member tenant not found errors started occurring and knowledge retrieval observations have stopped being sent.

Originally created by @TamatamaAlex on GitHub (Jan 21, 2026). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.11.4 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce Removing a member who has created an app/workflow from a workspace causes traces being sent to 3rd party applications (in this case Langfuse) to cause tenant not found errors. ``` worker-1 | 2026-01-22 01:43:11.970 INFO [Dummy-3] [ops_trace_manager.py:355] d6eaefef1b775f798a2aa5e9744970e9 - new tracing_instance for app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9 worker-1 | 2026-01-22 01:43:11.973 INFO [Dummy-3] [ops_trace_task.py:48] d6eaefef1b775f798a2aa5e9744970e9 - Processing trace tasks success, app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9 worker-1 | 2026-01-22 01:43:11.998 INFO [Dummy-3] [trace.py:128] d6eaefef1b775f798a2aa5e9744970e9 - Task tasks.ops_trace_task.process_trace_tasks[29d475a1-394c-4023-b7fb-a19830f82b8b] succeeded in 0.7747870711609721s: None worker-1 | 2026-01-22 01:43:13.221 INFO [MainThread] [strategy.py:161] - Task tasks.ops_trace_task.process_trace_tasks[74318146-f9f7-4e0a-ac74-6217c93138d6] received worker-1 | 2026-01-22 01:43:13.301 INFO [Dummy-5] [ops_trace_task.py:50] a59a267af5df5efa97a73817d829c420 - error: worker-1 | worker-1 | worker-1 | Current tenant not found for account c55361b6-9877-447e-b6b4-49546d7986f3 worker-1 | worker-1 | worker-1 | worker-1 | worker-1 | 2026-01-22 01:43:13.302 INFO [Dummy-5] [ops_trace_task.py:53] a59a267af5df5efa97a73817d829c420 - Processing trace tasks failed, app_id: 0c767a1d-0f58-44b2-b68c-9aef6ce752f9 worker-1 | 2026-01-22 01:43:13.326 INFO [Dummy-5] [trace.py:128] a59a267af5df5efa97a73817d829c420 - Task tasks.ops_trace_task.process_trace_tasks[74318146-f9f7-4e0a-ac74-6217c93138d6] succeeded in 0.10417425213381648s: None worker-1 | 2026-01-22 01:43:26.026 INFO [MainThread] [strategy.py:161] - Task schedule.workflow_schedule_task.poll_workflow_schedules[0784563c-924b-45ea-ad69-7362f97123c4] received worker-1 | 2026-01-22 01:43:26.405 INFO [Dummy-6] [trace.py:128] d6429b279648528a96121549e4da2f38 - Task schedule.workflow_schedule_task.poll_workflow_schedules[0784563c-924b-45ea-ad69-7362f97123c4] succeeded in 0.37737353704869747s: None ``` My best guess is that due to the 'created_by' in the PostgreSQL database remaining set to the old member's uuid, the tracing configuration has also been affected. However, I had also updated Dify from version 1.11.1 to 1.11.2 around that same timeframe. Updating to 1.11.4 has not fixed the error. I also noticed that despite removing the member from the workspace, their login information is still present in the database under public.accounts, but the worker container can't find the tenant it appears. I haven't tried manually changing the owner/created_by to be someone else for the app yet, but I wonder if that would fix the issue. No errors have been found for Langfuse's container. ### ✔️ Expected Behavior Observations in Langfuse had shown knowledge retrieval information, such as what knowledge was read by the app. ### ❌ Actual Behavior All knowledge retrieval observations have disappeared, but the normal workflow observations are still present. In summary: Before updating to >=1.11.2 and before removing a member from workspace there were knowledge retrieval observations being sent to langfuse. After updating and removing the member tenant not found errors started occurring and knowledge retrieval observations have stopped being sent.
yindo added the 🐞 bug label 2026-02-21 20:14:29 -05:00
yindo commented 2026-02-21 20:14:29 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 21, 2026):

This happens because when you remove a workspace member, Dify does not update the created_by field in apps, workflows, or related tables. If the created_by UUID points to a user who is no longer a tenant member, tenant resolution fails for any process that relies on that reference—this breaks knowledge retrieval and tracing, resulting in "tenant not found" errors in the worker container, while other logs (like workflow logs) may still work if they don't depend on the removed account's tenant context see code details.

There is no built-in tool or admin script to fix this. The only way to resolve it is to manually update the created_by field in the affected tables (such as apps, workflows, workflow_runs, etc.) to a valid account UUID that is still a member of the tenant. For example, in PostgreSQL:

-- Replace 'old-uuid' with the removed member's UUID and 'new-uuid' with a valid admin's UUID
UPDATE apps SET created_by = 'new-uuid' WHERE created_by = 'old-uuid';
UPDATE workflows SET created_by = 'new-uuid' WHERE created_by = 'old-uuid';
-- Repeat for other tables as needed

Before making changes, back up your database. After updating, restart your worker containers to clear any cached state.

For long-term stability, consider proposing or contributing a feature to Dify that reassigns or nullifies ownership fields when a member is removed, or implement defensive checks in your custom workflow nodes/plugins to ensure all UUID references are valid.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 21, 2026): <!-- Answer --> This happens because when you remove a workspace member, Dify does not update the `created_by` field in apps, workflows, or related tables. If the `created_by` UUID points to a user who is no longer a tenant member, tenant resolution fails for any process that relies on that reference—this breaks knowledge retrieval and tracing, resulting in "tenant not found" errors in the worker container, while other logs (like workflow logs) may still work if they don't depend on the removed account's tenant context [see code details](https://github.com/langgenius/dify/blob/211c57f7b62fe3578c77fcb00aebc5760e8e5466/api/controllers/console/workspace/members.py#L158-L383). There is no built-in tool or admin script to fix this. The only way to resolve it is to manually update the `created_by` field in the affected tables (such as `apps`, `workflows`, `workflow_runs`, etc.) to a valid account UUID that is still a member of the tenant. For example, in PostgreSQL: ```sql -- Replace 'old-uuid' with the removed member's UUID and 'new-uuid' with a valid admin's UUID UPDATE apps SET created_by = 'new-uuid' WHERE created_by = 'old-uuid'; UPDATE workflows SET created_by = 'new-uuid' WHERE created_by = 'old-uuid'; -- Repeat for other tables as needed ``` Before making changes, back up your database. After updating, restart your worker containers to clear any cached state. For long-term stability, consider proposing or contributing a feature to Dify that reassigns or nullifies ownership fields when a member is removed, or implement defensive checks in your custom workflow nodes/plugins to ensure all UUID references are valid. <!-- 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/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/64268e43-8fe7-4a13-839b-711a2d95d3b3?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=This%20happens%20because%20when%20you%20remove%20a%20workspace%20member%2C%20Dify%20does%20not%20update%20the%20%60created_by%60%20field%20in%20apps%2C%20workflows%2C%20or%20related%20tables.%20If%20the%20%60created_by%60%20UUID%20points%20to%20a%20user%20who%20is%20no%20longer%20a%20tenant%20member%2C%20tenant%20resolution%20fails%20for%20any%20process%20that%20relies%20on%20that%20reference%E2%80%94this%20breaks%20knowledge%20retrieval%20and%20tracing%2C%20resulting%20in%20%22tenant%20not%20found%22%20errors%20in%20the%20worker%20container%2C%20while%20other%20logs%20%28like%20workflow%20logs%29%20may%20still%20work%20if%20they%20don%27t%20depend%20on%20the%20removed%20account%27s%20tenant%20context%C2%A0%5Bsee%20code%20details%5D%28https%3A//github.com/langgenius/dify/blob/211c57f7b62fe3578c77fcb00aebc5760e8e5466/api/controllers/console/workspace/members.py%23L158-L383%29.%0A%0AThere%20is%20no%20built-in%20tool%20or%20admin%20script%20to%20fix%20this.%20The%20only%20way%20to%20resolve%20it%20is%20to%20manually%20update%20the%20%60created_by%60%20field%20in%20the%20affected%20tables%20%28such%20as%20%60apps%60%2C%20%60workflows%60%2C%20%60workflow_runs%60%2C%20etc.%29%20to%20a%20valid%20account%20UUID%20that%20is%20still%20a%20member%20of%20the%20tenant.%20For%20example%2C%20in%20PostgreSQL%3A%0A%0A%60%60%60sql%0A--%20Replace%20%27old-uuid%27%20with%20the%20removed%20member%27s%20UUID%20and%20%27new-uuid%27%20with%20a%20valid%20admin%27s%20UUID%0AUPDATE%20apps%20SET%20created_by%20%3D%20%27new-uuid%27%20WHERE%20created_by%20%3D%20%27old-uuid%27%3B%0AUPDATE%20workflows%20SET%20created_by%20%3D%20%27new-uuid%27%20WHERE%20created_by%20%3D%20%27old-uuid%27%3B%0A--%20Repeat%20for%20other%20tables%20as%20needed%0A%60%60%60%0A%0ABefore%20making%20changes%2C%20back%20up%20your%20database.%20After%20updating%2C%20restart%20your%20worker%20containers%20to%20clear%20any%20cached%20state.%0A%0AFor%20long-term%20stability%2C%20consider%20proposing%20or%20contributing%20a%20feature%20to%20Dify%20that%20reassigns%20or%20nullifies%20ownership%20fields%20when%20a%20member%20is%20removed%2C%20or%20implement%20defensive%20checks%20in%20your%20custom%20workflow%20nodes/plugins%20to%20ensure%20all%20UUID%20references%20are%20valid.)&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/31369)
yindo commented 2026-02-21 20:14:29 -05:00
Author
Owner
Copy Link
Copy Source

@TamatamaAlex commented on GitHub (Jan 25, 2026):

@dosu After confirming where I believe the code for this issue is (account_service.py), would this possibly be an acceptable fix for the issue? After removing the member we can reassign the created_by to the owner or the user that is calling the remove member operation:

@staticmethod
def remove_member_from_tenant(tenant: Tenant, account: Account, operator: Account) -> None:
    """Remove member from tenant"""
    if operator.id == account.id and TenantService.check_member_permission(tenant, operator, account, "remove"):
        raise CannotOperateSelfError("Cannot operate self.")
    
    ta = TenantAccountJoin.query.filter_by(tenant_id=tenant.id, account_id=account.id).first()
    if not ta:
        raise MemberNotInTenantError("Member not in tenant.")
    
    # Reassign created_by for all resources to a valid tenant member (e.g., operator or owner)
    from models.model import App
    from models.workflow import Workflow, WorkflowRun
    
    # Get a valid replacement account (owner or operator)
    owner_ta = TenantAccountJoin.query.filter_by(
        tenant_id=tenant.id, 
        role=TenantAccountJoinRole.OWNER.value
    ).first()
    replacement_id = owner_ta.account_id if owner_ta else operator.id
    
    # Update apps created by the removed user
    App.query.filter_by(
        tenant_id=tenant.id, 
        created_by=account.id
    ).update({"created_by": replacement_id})
    
    # Update workflows
    Workflow.query.filter_by(
        tenant_id=tenant.id, 
        created_by=account.id
    ).update({"created_by": replacement_id})
    
    # Update workflow runs if needed
    WorkflowRun.query.filter_by(
        tenant_id=tenant.id, 
        created_by=account.id
    ).update({"created_by": replacement_id})
    
    db.session.delete(ta)
    db.session.commit()
@TamatamaAlex commented on GitHub (Jan 25, 2026): @dosu After confirming where I believe the code for this issue is ([account_service.py](https://github.com/langgenius/dify/blob/main/api/services/account_service.py#L1216)), would this possibly be an acceptable fix for the issue? After removing the member we can reassign the created_by to the owner or the user that is calling the remove member operation: ```python @staticmethod def remove_member_from_tenant(tenant: Tenant, account: Account, operator: Account) -> None: """Remove member from tenant""" if operator.id == account.id and TenantService.check_member_permission(tenant, operator, account, "remove"): raise CannotOperateSelfError("Cannot operate self.") ta = TenantAccountJoin.query.filter_by(tenant_id=tenant.id, account_id=account.id).first() if not ta: raise MemberNotInTenantError("Member not in tenant.") # Reassign created_by for all resources to a valid tenant member (e.g., operator or owner) from models.model import App from models.workflow import Workflow, WorkflowRun # Get a valid replacement account (owner or operator) owner_ta = TenantAccountJoin.query.filter_by( tenant_id=tenant.id, role=TenantAccountJoinRole.OWNER.value ).first() replacement_id = owner_ta.account_id if owner_ta else operator.id # Update apps created by the removed user App.query.filter_by( tenant_id=tenant.id, created_by=account.id ).update({"created_by": replacement_id}) # Update workflows Workflow.query.filter_by( tenant_id=tenant.id, created_by=account.id ).update({"created_by": replacement_id}) # Update workflow runs if needed WorkflowRun.query.filter_by( tenant_id=tenant.id, created_by=account.id ).update({"created_by": replacement_id}) db.session.delete(ta) db.session.commit() ```
yindo commented 2026-02-21 20:14:29 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 25, 2026):

Your fix is on the right track and will resolve the "tenant not found" errors for resources in the App, Workflow, and WorkflowRun tables. However, Dify uses the created_by field in many other tables that also need updating to fully prevent orphaned references and downstream errors. These include (but aren't limited to): MessageFile, DatasetRetrieverResource, Tag, TagBinding, Site, UploadFile, MessageAgentThought, WorkflowNodeExecutionModel, WorkflowAppLog, WorkflowArchiveLog, WorkflowWebhookTrigger, InstalledApp, AppMCPServer, pinned_conversations, saved_messages, and app_model_configs see model definitions and migrations.

To make your solution robust, extend your update logic to cover all these tables. There’s no built-in audit log for ownership changes, so if you need compliance or history, consider adding logging or notifications. Dify doesn’t have automatic ownership transfer—manual updates are required see migration history.

In summary: your approach is correct, but for completeness, update all tables with a created_by field. This will ensure referential integrity and prevent future tenant/account resolution errors.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 25, 2026): <!-- Answer --> Your fix is on the right track and will resolve the "tenant not found" errors for resources in the App, Workflow, and WorkflowRun tables. However, Dify uses the `created_by` field in many other tables that also need updating to fully prevent orphaned references and downstream errors. These include (but aren't limited to): MessageFile, DatasetRetrieverResource, Tag, TagBinding, Site, UploadFile, MessageAgentThought, WorkflowNodeExecutionModel, WorkflowAppLog, WorkflowArchiveLog, WorkflowWebhookTrigger, InstalledApp, AppMCPServer, pinned_conversations, saved_messages, and app_model_configs [see model definitions and migrations](https://github.com/langgenius/dify/blob/9d38af6d99d6a2f2b64004895d154ae5d59ca64d/api/models/model.py#L36-L2110). To make your solution robust, extend your update logic to cover all these tables. There’s no built-in audit log for ownership changes, so if you need compliance or history, consider adding logging or notifications. Dify doesn’t have automatic ownership transfer—manual updates are required [see migration history](https://github.com/langgenius/dify/blob/9d38af6d99d6a2f2b64004895d154ae5d59ca64d/api/migrations/versions/2024_08_25_0441-d0187d6a88dd_add_created_by_and_updated_by_to_app_.py#L23-L33). In summary: your approach is correct, but for completeness, update all tables with a `created_by` field. This will ensure referential integrity and prevent future tenant/account resolution errors. <!-- 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/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/aede6431-58c0-45c6-923d-df12b86ea336?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Your%20fix%20is%20on%20the%20right%20track%20and%20will%20resolve%20the%20%22tenant%20not%20found%22%20errors%20for%20resources%20in%20the%20App%2C%20Workflow%2C%20and%20WorkflowRun%20tables.%20However%2C%20Dify%20uses%20the%20%60created_by%60%20field%20in%20many%20other%20tables%20that%20also%20need%20updating%20to%20fully%20prevent%20orphaned%20references%20and%20downstream%20errors.%20These%20include%20%28but%20aren%27t%20limited%20to%29%3A%20MessageFile%2C%20DatasetRetrieverResource%2C%20Tag%2C%20TagBinding%2C%20Site%2C%20UploadFile%2C%20MessageAgentThought%2C%20WorkflowNodeExecutionModel%2C%20WorkflowAppLog%2C%20WorkflowArchiveLog%2C%20WorkflowWebhookTrigger%2C%20InstalledApp%2C%20AppMCPServer%2C%20pinned_conversations%2C%20saved_messages%2C%20and%20app_model_configs%C2%A0%5Bsee%20model%20definitions%20and%20migrations%5D%28https%3A//github.com/langgenius/dify/blob/9d38af6d99d6a2f2b64004895d154ae5d59ca64d/api/models/model.py%23L36-L2110%29.%0A%0ATo%20make%20your%20solution%20robust%2C%20extend%20your%20update%20logic%20to%20cover%20all%20these%20tables.%20There%E2%80%99s%20no%20built-in%20audit%20log%20for%20ownership%20changes%2C%20so%20if%20you%20need%20compliance%20or%20history%2C%20consider%20adding%20logging%20or%20notifications.%20Dify%20doesn%E2%80%99t%20have%20automatic%20ownership%20transfer%E2%80%94manual%20updates%20are%20required%C2%A0%5Bsee%20migration%20history%5D%28https%3A//github.com/langgenius/dify/blob/9d38af6d99d6a2f2b64004895d154ae5d59ca64d/api/migrations/versions/2024_08_25_0441-d0187d6a88dd_add_created_by_and_updated_by_to_app_.py%23L23-L33%29.%0A%0AIn%20summary%3A%20your%20approach%20is%20correct%2C%20but%20for%20completeness%2C%20update%20all%20tables%20with%20a%20%60created_by%60%20field.%20This%20will%20ensure%20referential%20integrity%20and%20prevent%20future%20tenant/account%20resolution%20errors.)&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/31369)
yindo commented 2026-02-21 20:14:30 -05:00
Author
Owner
Copy Link
Copy Source

@TamatamaAlex commented on GitHub (Jan 29, 2026):

@dosubot Perhaps implementing an option to change owners in the console is a better plan.

@TamatamaAlex commented on GitHub (Jan 29, 2026): @dosubot Perhaps implementing an option to change owners in the console is a better plan.
yindo commented 2026-02-21 20:14:30 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 29, 2026):

Implementing an option to change owners in the console is a solid plan and aligns with best practices for multi-user platforms. Dify already supports secure workspace owner transfer in the UI, but this only updates the workspace-level owner and does not reassign the created_by field for individual resources like apps, workflows, or datasets—so orphaned references can still cause issues when members are removed see code/UI and API.

To fully solve the orphaned resource problem, a resource-level owner change feature would need to update the created_by field across all relevant tables (apps, workflows, datasets, etc.) and provide a UI for admins/owners to reassign ownership before removing a member. This would require backend changes (model, service, controller, migrations) and frontend work (UI, API integration), similar to how dataset permissions are managed discussion.

Keep in mind: Dify’s audit logging is currently limited, so tracking ownership changes for compliance is not comprehensive in the community version reference. If you implement this, consider atomic updates and clear user feedback to avoid partial changes or confusion.

This feature would make ownership management much safer and more user-friendly than manual DB edits, and would prevent the “tenant not found” errors you’ve encountered.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Jan 29, 2026): <!-- Answer --> Implementing an option to change owners in the console is a solid plan and aligns with best practices for multi-user platforms. Dify already supports secure workspace owner transfer in the UI, but this only updates the workspace-level owner and does not reassign the created_by field for individual resources like apps, workflows, or datasets—so orphaned references can still cause issues when members are removed [see code/UI](https://github.com/langgenius/dify/blob/03e3acfc710750e18cc30d9cd0b8af3d93a26e2b/web/app/components/header/account-setting/members-page/transfer-ownership-modal/index.tsx) [and API](https://github.com/langgenius/dify/blob/03e3acfc710750e18cc30d9cd0b8af3d93a26e2b/api/controllers/console/workspace/members.py#L198-L390). To fully solve the orphaned resource problem, a resource-level owner change feature would need to update the created_by field across all relevant tables (apps, workflows, datasets, etc.) and provide a UI for admins/owners to reassign ownership before removing a member. This would require backend changes (model, service, controller, migrations) and frontend work (UI, API integration), similar to how dataset permissions are managed [discussion](https://github.com/langgenius/dify/discussions/27752#discussioncomment-14920338). Keep in mind: Dify’s audit logging is currently limited, so tracking ownership changes for compliance is not comprehensive in the community version [reference](https://github.com/langgenius/dify/issues/22827). If you implement this, consider atomic updates and clear user feedback to avoid partial changes or confusion. This feature would make ownership management much safer and more user-friendly than manual DB edits, and would prevent the “tenant not found” errors you’ve encountered. <!-- 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/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c4160873-bbe3-4d05-8198-18c3ede02b0f?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Implementing%20an%20option%20to%20change%20owners%20in%20the%20console%20is%20a%20solid%20plan%20and%20aligns%20with%20best%20practices%20for%20multi-user%20platforms.%20Dify%20already%20supports%20secure%20workspace%20owner%20transfer%20in%20the%20UI%2C%20but%20this%20only%20updates%20the%20workspace-level%20owner%20and%20does%20not%20reassign%20the%20created_by%20field%20for%20individual%20resources%20like%20apps%2C%20workflows%2C%20or%20datasets%E2%80%94so%20orphaned%20references%20can%20still%20cause%20issues%20when%20members%20are%20removed%C2%A0%5Bsee%20code/UI%5D%28https%3A//github.com/langgenius/dify/blob/03e3acfc710750e18cc30d9cd0b8af3d93a26e2b/web/app/components/header/account-setting/members-page/transfer-ownership-modal/index.tsx%29%C2%A0%5Band%20API%5D%28https%3A//github.com/langgenius/dify/blob/03e3acfc710750e18cc30d9cd0b8af3d93a26e2b/api/controllers/console/workspace/members.py%23L198-L390%29.%0A%0ATo%20fully%20solve%20the%20orphaned%20resource%20problem%2C%20a%20resource-level%20owner%20change%20feature%20would%20need%20to%20update%20the%20created_by%20field%20across%20all%20relevant%20tables%20%28apps%2C%20workflows%2C%20datasets%2C%20etc.%29%20and%20provide%20a%20UI%20for%20admins/owners%20to%20reassign%20ownership%20before%20removing%20a%20member.%20This%20would%20require%20backend%20changes%20%28model%2C%20service%2C%20controller%2C%20migrations%29%20and%20frontend%20work%20%28UI%2C%20API%20integration%29%2C%20similar%20to%20how%20dataset%20permissions%20are%20managed%C2%A0%5Bdiscussion%5D%28https%3A//github.com/langgenius/dify/discussions/27752%23discussioncomment-14920338%29.%0A%0AKeep%20in%20mind%3A%20Dify%E2%80%99s%20audit%20logging%20is%20currently%20limited%2C%20so%20tracking%20ownership%20changes%20for%20compliance%20is%20not%20comprehensive%20in%20the%20community%20version%C2%A0%5Breference%5D%28https%3A//github.com/langgenius/dify/issues/22827%29.%20If%20you%20implement%20this%2C%20consider%20atomic%20updates%20and%20clear%20user%20feedback%20to%20avoid%20partial%20changes%20or%20confusion.%0A%0AThis%20feature%20would%20make%20ownership%20management%20much%20safer%20and%20more%20user-friendly%20than%20manual%20DB%20edits%2C%20and%20would%20prevent%20the%20%E2%80%9Ctenant%20not%20found%E2%80%9D%20errors%20you%E2%80%99ve%20encountered.)&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/31369)
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#21823
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?