1.14.0-rc1: Skill creation fails on UI (CORS to api:5001) but creates a ghost record, leading to 500 FileNotFoundError upon editing

[shuo1104]

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

Version1.14.0-rc1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The following is from my AI assistant：

Description:
In version 1.14.0-rc1 (Docker Compose deployment), creating a new Skill fails due to network/CORS errors on the frontend, but a database record is still created without rolling back. Because the physical skill.md file is never written to the OpenDAL storage, attempting to edit this "ghost" Skill subsequently triggers a 500 Internal Server Error (FileNotFoundError) in the API.

Steps to Reproduce:

1. Deploy Dify 1.14.0-rc1 using the default Docker Compose configuration.
2. Navigate to the frontend and attempt to create a new Skill.
3. Observe that the UI indicates a creation failure. The browser console shows CORS errors attempting to reach the internal Docker hostname (http://api:5001).
4. Notice that despite the UI failure, the Skill appears in the workspace list (database record was created).
5. Click on the newly created Skill to edit it (skill.md).
6. A 500 Internal Server Error occurs.

Expected Behavior:

1. The frontend should use the correct external API URL, not the internal container address (http://api:5001).
2. If the physical file fails to be created/uploaded via OpenDAL, the database transaction should be rolled back so no "ghost" Skill appears in the list.
3. File writing to local storage using OpenDAL should succeed with default configurations.

Actual Behavior / Root Causes Identified:

1. Frontend CORS Error (Calling internal Docker hostname):
During Skill creation, the frontend attempts to call http://api:5001 directly instead of routing through the Nginx proxy (localhost or domain), leading to a CORS block:

Access to XMLHttpRequest at 'http://api:5001/files/storage-files/4c31630a-566d-4f84-aa4e-04b6fd62e7cd' from origin 'http://localhost' has been blocked by CORS policy...
net::ERR_FAILED

2. Missing Database Rollback:
Because the file upload/creation fails, the API throws an error to the frontend, but the initial database record for the Skill remains.

3. API 500 Error (OpenDAL File Not Found):
When attempting to open the ghost Skill, the API correctly looks for the file but OpenDAL throws a FileNotFoundError because it was never saved:

  # ... (Traceback omitted for brevity) ...
  File "/app/api/services/app_asset_service.py", line 226, in get_file_content
    return asset_storage.load_once(key)
  File "/app/api/extensions/storage/opendal_storage.py", line 49, in load_once
    raise FileNotFoundError("File not found")
FileNotFoundError: File not found

Environment:

• Dify Version: 1.14.0-rc1
• Deployment: Docker Compose
• Storage: STORAGE_TYPE=opendal, OPENDAL_SCHEME=fs, OPENDAL_FS_ROOT=storage

Troubleshooting Already Performed (For Maintainers' Reference):

• Permissions: Executed chmod -R 777 volumes/ on the host machine. The issue persists, confirming the file is genuinely not being written, rather than just a permission block on read.
• Pathing: Changed OPENDAL_FS_ROOT to an absolute path (/app/api/storage) in .env. Did not resolve the issue.
• WebSocket Fix: Initially encountered The gevent-websocket server is not configured appropriately upon clicking the Skill. Fixed this by manually adding SERVER_WORKER_CLASS: geventwebsocket.gunicorn.workers.GeventWebSocketWorker to the api service in docker-compose.yaml (Might be another missing default config in rc1).
• Worker Logs: Checked worker container logs during creation; no errors were thrown there, indicating the failure is synchronous in the API/Frontend interaction.

[dosubot]

Hi @shuo1104! I'm Dosu and I’m helping the dify team.

This issue has two distinct root causes that are known problems in Dify Docker deployments:

1. CORS Error: Frontend calling internal Docker hostname

The frontend is calling http://api:5001 (Docker-internal hostname) instead of routing through your external proxy. This is a known URL configuration issue affecting file uploads in Docker deployments.

Fix: Update your .env file to use browser-accessible URLs, not Docker-internal addresses:

# Replace with your actual host IP or domain
CONSOLE_API_URL=http://your-external-ip-or-domain
APP_API_URL=http://your-external-ip-or-domain
FILES_URL=http://your-external-ip-or-domain:5001
INTERNAL_FILES_URL=http://api:5001  # This one stays internal

# CORS settings
WEB_API_CORS_ALLOW_ORIGINS=*
CONSOLE_CORS_ALLOW_ORIGINS=*

Also ensure port 5001 is exposed in your docker-compose.yml:

services:
  api:
    ports:
      - "5001:5001"

2. Ghost Records (Missing Transaction Rollback)

The "ghost" Skill issue—where the database record exists but the physical file doesn't—is a known problem where creation operations don't roll back the database when file storage fails. PRs #31829 and #31805 address transaction rollback for failed creation operations, but these weren't merged in 1.14.0-rc1.

For now, orphaned records need to be manually cleaned from the database.

One additional note: The "Agent Skills" feature based on the Anthropic standard is still in planning stages according to maintainer feedback. If you're testing this feature, it may be from an experimental branch—could you confirm where you enabled it?

To reply, just mention @dosu.

---

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

   

[dataCenter430]

@shuo1104 thank you for reporting this.
I will fix it soon.
@dosu are you able to assign it to me?

[guanyvbai]

@dataCenter430 I also encountered the same problem. It still failed to upload after using this configuration.The nginx configuration that comes with the deployment is used.Looking forward to your fix

[dataCenter430]

@guanyvbai thank you for calling this out.
yup, no problem.
I will fix it soon.

[dataCenter430]

@lyzno1 could you pls assign it to me, if needed? thank you

[lyzno1]

@shuo1104 Please update to the latest code in the feat/support-agent-sandbox branch before redeploying.

[shuo1104]

@shuo1104请先将分支中的代码更新到最新版本，feat/support-agent-sandbox然后再重新部署。

I have updated the code to the latest version, feat/support-agent-sandbox branch does not seem to solve my problem, the error has not changed at all