Debugging File Upload & Logging Issues on Platform.sh

Introduction

A client using Platform.sh — a lesser-known but powerful PaaS (Platform as a Service) — encountered two persistent issues during their Symfony-based application development. The problems involved missing logs in production and server-side event (SSE) failures when uploading data via CSV.

Despite attempts by their team to resolve these bugs, the root causes remained unclear for over a month. We stepped in to help untangle the problem and restore reliability to their development workflow.

Background: What is Platform.sh?

Platform.sh is a Git-based continuous deployment cloud platform. Developers push code to a connected GitHub repository, and Platform.sh automatically builds and deploys the application based on its configuration files (mainly .platform.app.yaml, .platform/routes.yaml, and .platform/services.yaml).

Beyond simple app hosting, Platform.sh provisions isolated containers for each service (web, worker, database, etc.), automatically handles reverse proxy configuration, and supports environment-specific branching and cloning — making it well-suited for Symfony and other monolithic or microservice PHP stacks.

The Issues

1. Logging: Production Logs Missing in Platform.sh

The client noticed that database operation logs were visible locally, but disappeared in production. They attempted to inspect logs by SSHing into the server but couldn’t find the expected output.

2. SSE Failure During File Upload Processing

The client’s application allowed users to upload CSV files on the frontend, which would then be processed by a Symfony worker. Progress updates were pushed to the frontend via Mercure using Server-Sent Events (SSE).

In the local environment, the process worked for small files (~1.1KB), but failed when uploading larger files (~2MB, ~5000 records).
On Platform.sh (production), the process failed for both small and large files, with the SSE stream not initiating at all.

Initially, the client suspected that the file size was the root cause — but our investigation revealed a deeper architectural issue.

Our Solution

We quickly dove into both the platform and codebase. Here’s how we resolved both problems:

🔧 1. Fixing Logging in Platform.sh

Learned the platform’s internal structure
We familiarized ourselves with Platform.sh’s architecture and its read-only container behavior, environment-specific mounts, and log stream structure.
Traced Symfony Monolog Configuration
The log path defined in the Symfony configuration pointed to a location that was read-only in Platform.sh. This folder was symlinked from a different internal mount, causing logs to silently fail.
Updated Logging Paths and Levels
We updated the Monolog config to correctly use the writable directories provided by Platform.sh ($PLATFORM_APP_DIR or the environment-specific mounts) and explicitly set different logging levels for dev and prod.

✅ Result: Logs now show as expected in production when accessed via Platform.sh’s logging tools or SSH, greatly improving observability.

🔧 2. Resolving File Upload & SSE Worker Failures

Analyzed the Actual Code Flow
The client’s assumption was that the file size caused the SSE failure. But we dug into Symfony’s worker logic and saw the real problem.
Uncovered Service Isolation Issue
In Platform.sh, each container runs in an isolated environment. The main API server and the Symfony worker were not sharing a filesystem. Thus, files uploaded to the API server were not visible to the worker.
Introduced Network Storage
Platform.sh supports a dedicated shared volume service. We configured a third service Network Storage as a shared volume between the web and worker containers. This allowed the uploaded file to persist and be accessed from both services.
Debugged Further on File Parsing
After fixing the file visibility, a larger file (2MB) still failed. We identified the cause: a single broken record inside the file that wasn’t handled correctly by the existing codebase. The error wasn’t due to size but rather an unhandled edge case.

✅ Result: The production app can now handle both small and large files without failure, and frontend SSE updates are correctly streamed from the worker via Mercure.