bug: P0: docker-provider memory leak due to full log buffering in getHttpServerPort #2894
Description
Provide environment information
System:
OS: Windows 11 10.0.26200
CPU: (12) x64 12th Gen Intel(R) Core(TM) i5-1235U
Memory: 2.19 GB / 15.70 GB
Binaries:
Node: 22.21.1 - C:\nvm4w\nodejs\node.EXE
npm: 10.9.4 - C:\nvm4w\nodejs\npm.CMD
pnpm: 10.23.0 - C:\nvm4w\nodejs\pnpm.CMD
bun: 1.3.6 - C:\nvm4w\nodejs\bun.CMD
Managers:
Cargo: 1.86.0 - C:\Users\bhara.cargo\bin\cargo.EXE
Composer: 2.9.2 - C:\composer\composer.BAT
Utilities:
CMake: 3.31.6 - C:\Program Files\CMake\bin\cmake.EXE
Git: 2.47.1. - C:\Program Files\Git\cmd\git.EXE
Git LFS: 3.6.0 - C:\Program Files\Git\cmd\git-lfs.EXE
Curl: 8.16.0 - C:\WINDOWS\system32\curl.EXE
Virtualization:
Docker: 27.1.1 - C:\Program Files\Docker\Docker\resources\bin\docker.EXE
Docker Compose: 2.29.1 - C:\Program Files\Docker\Docker\resources\bin\docker-compose.EXE
IDEs:
Android Studio: AI-242.23339.11.2421.12550806
VSCode: 1.107.1 - C:\Users\bhara\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
Cursor: 2.3.30 - C:\Program Files\cursor\resources\app\bin\cursor.CMD
Languages:
Bash: 5.1.16 - C:\WINDOWS\system32\bash.EXE
PHP: 8.3.26 - C:\laragon\bin\php\php-8.3.26-Win32-vs16-x64\php.EXE
Python: 3.11.0 - C:\Users\bhara\AppData\Local\Programs\Python\Python311\python.EXE
Rust: 1.86.0 - C:\Users\bhara.cargo\bin\rustc.EXE
Databases:
SQLite: 3.51.1 - C:\sqlite\sqlite3.EXE
Browsers:
Chrome: 143.0.7499.193
Edge: Chromium (140.0.3485.54)
Internet Explorer: 11.0.26100.7309
Describe the bug
docker-provider currently reads the entire container stdout into memory to detect the HTTP server port via the getHttpServerPort function.
For long-running containers (e.g., those active for days) or tasks with verbose logging, docker logs returns the complete history, which can be gigabytes in size. This causes:
Memory Leaks/OOM: Loading GBs of strings into the Node.js heap.
Event Loop Blocking: Regex matching against massive strings freezes the provider.
Operational Risk: Causes provider instability and requires over-provisioning.
Reproduction repo
N/A (Architecture issue in apps/docker-provider
To reproduce
- Start a Trigger.dev instance using the Docker provider.
- Run a task that yields a large amount of logs (simulating a long-running process).
- Trigger an operation that calls getHttpServerPort (e.g., a restart or restore event).
- Observe the memory usage of the docker-provider service spike significantly as it buffers the full log history.
Additional information
Proposed Mitigation: I have prepared a fix that refactors getHttpServerPort to use log streaming.
Spawns docker logs with a pipe.
Scans stdout line-by-line.
Exits early as soon as the port is found.
Includes a 10s timeout to prevent hanging.