Hello Railway Team,

I am writing to report a critical issue where my application's file writes are not being persisted to its mounted volume. All diagnostic tests performed from within the running application show success, but the files are immediately lost, indicating that writes are being directed to a temporary or ephemeral filesystem layer instead of the actual persistent volume.

---

### 1. The Environment

*   **Service:** FastAPI application deployed on Railway.
*   **Volume:** A persistent volume is correctly mounted at `/app/assets`.
*   **Permissions:** The service is running with `RAILWAY_RUN_UID=0`. My Start Command also successfully runs `chown -R root:root /app/assets` before the application starts.
*   **Start Command:**
    ```bash
    chown -R root:root /app/assets && mkdir -p /app/assets/uploads ... && uvicorn app.main:app ...
    ```

---

### 2. The Core Problem: Contradictory Evidence

There is a clear contradiction between what my running application process sees and what is actually stored on the persistent volume.

**A. The Application Process View (From a Diagnostic Endpoint):**
My diagnostic endpoint performs a write, wait, and read test. The logs from this test show a complete success from the application's perspective:

```
--- Diagnostic Results ---
INFO: Process running as UID: 0
INFO: settings.ASSETS_DIR is configured as: /assets
INFO: Absolute path of ASSETS_DIR is: /assets
INFO: Directory '/assets' exists.
INFO: Contents of '/assets': ['uploads', 'results', 'frames', ...]
INFO: Successfully ensured test directory exists at: /assets/test_dir_from_web
INFO: Successfully wrote to test file: /assets/test_file_from_web.txt
INFO: Read test successful: File '/assets/test_file_from_web.txt' still exists after delay.
INFO: Content of test file: 'Hello from the web process.'
--- Diagnostic Results ---
```
This proves the running process, as `root`, has permission to create directories and write files within the `/assets` directory it sees.

**B. The Persistent Volume View (From the Railway File Browser):**
Despite the successful logs above, the file browser for my persistent volume shows that none of these write operations actually persisted.
*   The `test_dir_from_web` directory is **not** present.
*   The `test_file_from_web.txt` file is **not** present.
*   When I upload an image to `/app/assets/uploads`, the application logs a successful write, but the file **never appears** in the volume.

---

### 3. Conclusion

This evidence leads to one conclusion: **My running `uvicorn` process is not writing to the persistent volume.** It is writing to a temporary, ephemeral filesystem overlay that is discarded after the request is complete.

This explains why:
- The application reports success (it wrote to the temporary layer).
- A subsequent `GET` request for the same file results in a `404 Not Found` (the file doesn't exist on the persistent layer that the server reads from).

Could you please investigate my service's container and volume configuration to determine why writes from the running application process are not being saved to the persistent volume?