uploading file via API always has no response

[liaoyuanyi]

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.14.1 & 1.14.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When I upload any image or file through the "Send Dialog Message" API to my chatflow, the front end always displays "thinking" until it stops, with no response. When I check the Docker worker logs, the following error is reported:
ERROR [Dummy-3932] [trace.py:309] c24865ae719e52a6af155c5495e1ce2d - Task tasks.app_generate.workflow_execute_task.workflow_based_app_execution_task[6fb4fdf1-366e-443b-9f7e-512bc80b55ac] raised unexpected: ValueError('Invalid upload file')

2026-07-21 14:47:56 Traceback (most recent call last):

2026-07-21 14:47:56   File "/app/api/.venv/lib/python3.12/site-packages/celery/app/trace.py", line 585, in trace_task

2026-07-21 14:47:56     R = retval = fun(*args, **kwargs)

2026-07-21 14:47:56                  ^^^^^^^^^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/extensions/ext_celery.py", line 101, in call

2026-07-21 14:47:56     return self.run(*args, **kwargs)

2026-07-21 14:47:56            ^^^^^^^^^^^^^^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/tasks/app_generate/workflow_execute_task.py", line 269, in workflow_based_app_execution_task

2026-07-21 14:47:56     return runner.run()

2026-07-21 14:47:56            ^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/tasks/app_generate/workflow_execute_task.py", line 165, in run

2026-07-21 14:47:56     response = self._run_app(

2026-07-21 14:47:56                ^^^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/tasks/app_generate/workflow_execute_task.py", line 187, in _run_app

2026-07-21 14:47:56     return AdvancedChatAppGenerator().generate(

2026-07-21 14:47:56            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/core/app/apps/advanced_chat/app_generator.py", line 162, in generate

2026-07-21 14:47:56     file_objs = file_factory.build_from_mappings(

2026-07-21 14:47:56                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/factories/file_factory/builders.py", line 68, in build_from_mappings

2026-07-21 14:47:56     build_from_mapping(

2026-07-21 14:47:56   File "/app/api/factories/file_factory/builders.py", line 37, in build_from_mapping

2026-07-21 14:47:56     file = build_func(

2026-07-21 14:47:56            ^^^^^^^^^^^

2026-07-21 14:47:56   File "/app/api/factories/file_factory/builders.py", line 141, in _build_from_local_file

2026-07-21 14:47:56     raise ValueError("Invalid upload file")

2026-07-21 14:47:56 ValueError: Invalid upload file

✔️ Expected Behavior

The chatflow can respond to content normally.

❌ Actual Behavior

the front end always displays "thinking" until it stops, with no response.

[dosubot]

This Invalid upload file error is almost certainly caused by a user parameter mismatch between your file upload API call and your "Send Dialog Message" API call.

When you upload a file via the API, Dify stores it with the user identity you provide. When you then send a chat message referencing that file, the access controller filters by user_id — if the user parameter in the two calls doesn't match exactly, the file lookup returns nothing and raises ValueError("Invalid upload file") [1] [2].

This was confirmed by another user who hit the same issue — the user parameter was inconsistent between the two API calls, and it only started failing after Dify tightened its ownership checks.

Fix: Make sure the user parameter value is identical in both your file upload request and your chat message request. For example, if you upload with "user": "abc-123", the subsequent chat message must also use "user": "abc-123".

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[liaoyuanyi]

@dosu I have checked that user parameter value is consistent,but the problem is still alive.

[dosubot]

Thanks for confirming the user parameter is consistent. Let me dig into some other possible causes.

Since you're using a chatflow (Advanced Chat) and likely streaming mode, the file building happens inside a Celery worker rather than the original API request thread [1]. Here are a few things to check:

1. Try blocking mode instead of streaming.
If you're using "response_mode": "streaming", try switching to "response_mode": "blocking". In blocking mode, the workflow runs synchronously in the request thread rather than dispatching to Celery. If blocking mode works but streaming doesn't, it points to a context propagation issue in the Celery worker.

2. Verify the upload file ID format in your chat-messages request.
The file reference in your /v1/chat-messages body should look like this — make sure upload_file_id matches the id returned by the /v1/files/upload response:

{
  "files": [
    {
      "type": "image",
      "transfer_method": "local_file",
      "upload_file_id": "<id from upload response>"
    }
  ]
}

The system validates that the ID is a valid UUID [2], so any corruption in the ID would trigger the error.

3. Check the upload response.
Confirm that the /v1/files/upload call actually returns a successful response with a valid file id before you call /v1/chat-messages.

4. Check your database for the upload record.
You can query your database directly to verify the file exists and is owned by the correct end user:

SELECT id, tenant_id, created_by, created_by_role FROM upload_files WHERE id = '<upload_file_id>';

Then check that the created_by value matches the EndUser record associated with your user parameter:

SELECT id, session_id FROM end_users WHERE session_id = '<your_user_param>' AND app_id = '<your_app_id>';

The created_by on the upload file should match the id from the end_users table [3].

5. Are you using the correct API key?
The file upload and chat-messages calls must use the same app's API key. Each app has its own tenant/app scope, and files uploaded under one app cannot be accessed by another.

Could you share (with sensitive data redacted):

• The exact API requests you're making (both upload and chat-messages)?
• The response from the /v1/files/upload call?
• The database query results above?

This will help pinpoint which specific filter is rejecting the file.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[liaoyuanyi]

@dosu 我考虑想从1.14.2回退至1.13.3版本，似乎遇到了数据库迁移的报错[flask_migrate] Error: Can't locate revision identified。所以有什么正确的回滚方法么

[dosubot]

从 1.14.2 回退到 1.13.3 遇到 Can't locate revision identified 错误是预期的——因为当你切换到 1.13.3 的代码后，api/migrations/versions/ 目录里不包含 1.14.2 的迁移文件，但数据库的 alembic_version 表仍记录着 1.14.2 的 revision ID，Alembic 找不到这个 revision 就会报错 [1]。

Dify 不支持数据库反向迁移，没有官方的降级流程。安全的回退方法只有一个：

从备份恢复（推荐）：

docker compose down
# 切换到 1.13.3 代码
git checkout <1.13.3-tag>
docker compose pull
# 从升级前的数据库备份恢复
docker compose exec -T db psql -U postgres dify < backup_pre_1.14.2.sql
docker compose up -d

如果你没有升级前的备份，有一个风险较高的变通方法——用 flask db stamp 强制覆盖版本号：

# 先在 1.14.2 环境下查看 1.13.3 对应的 revision ID
# 然后切换到 1.13.3 代码后执行：
docker compose exec api flask db stamp <1.13.3_revision_id>

但这只修改版本记录，不会回退实际的表结构，数据库中会残留 1.14.2 新增的表和字段。1.13.3 的代码通常会忽略这些多余的表，但不能保证完全没有问题。

建议： 如果没有备份，更安全的做法是留在 1.14.2 上排查原始的文件上传问题。关于之前的 Invalid upload file 报错，你能否提供以下信息帮助进一步排查？

1. 你调用 /v1/files/upload 和 /v1/chat-messages 的具体请求参数（脱敏后）
2. /v1/files/upload 的返回结果
3. 使用的是 streaming 还是 blocking 模式？

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[SarangShelke2304]

Investigation notes (self-hosted Docker, Dify 1.14.2)

I tried to reproduce this on a local Docker Compose deploy of 1.14.2.

Setup

• Chatflow (Advanced Chat) with File Upload enabled
• Service API: POST /v1/files/upload then POST /v1/chat-messages with files[].transfer_method=local_file

Results

1. Same user on upload and chat-messages

• Upload succeeds
• Chatflow runs successfully (workflow_finished / status: succeeded)
• sys.files is populated correctly
• No ValueError: Invalid upload file in worker logs

2. Different user on upload vs chat-messages (upload as user-a, chat as user-b)

• API returns immediately:
  {"code":"invalid_param","message":"Invalid upload file","status":400}
• This matches the ownership check in _build_from_local_file / file access controller (upload is scoped to the end user who uploaded it)

Conclusion

On 1.14.2 I could not reproduce “thinking forever with no response” when user is identical across both calls. I can reproduce Invalid upload file by mismatching user.

@liaoyuanyi could you confirm:

1. The exact user value used in /v1/files/upload and /v1/chat-messages (are they identical, including casing/whitespace)?
2. That both calls use the same app API key?
3. response_mode (streaming vs blocking)?
4. A redacted sample of both request bodies (no API keys)?

If user already matches on your side, the remaining gap may be streaming error surfacing (UI hangs) vs a true lookup failure with matching ownership.
@dosu