SeleniumHQ / SeleniumHQ/docker-selenium
[🐛 Bug]: Logs from video recorder do not respect the SE_LOG_TIMESTAMP env variable
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 8.7k
- Forks
- 2.5k
- Avg merge
- 10h 16m
- Merged PRs (30d)
- 20
Description
What happened?
Hub and node containers allow you to set the timestamp format for logs using the SE_LOG_TIMESTAMP environment variable. However this does not seem to be supported in video containers. Furthermore, if you are using in node video recording then any logs in that node container that are from the video recorder do not obey the SE_LOG_TIMESTAMP variable. So you end up with logs of a mixed timestamp format which is messy and hard to read.
Video logs in the node container should obey this variable. Would also be nice if the video container supported this variable too
Command used to start Selenium Grid with Docker (or Kubernetes)
N/A
Relevant log output
2025-04-17 14:13:13,997 [video.recorder] - Video recording in progress
2025-04-17 14:13:15,005 [video.recorder] - Video recording in progress
14:13:15.327 INFO [LocalNode.stopTimedOutSession] - Session id 3f68c14543c3e232b7341e2de068a0ad is stopping on demand...
14:13:15.327 INFO [SessionSlot.stop] - Stopping session 3f68c14543c3e232b7341e2de068a0ad
Operating System
Ubuntu 20.04
Docker Selenium version (image tag)
4.31.0-20250404
Selenium Grid chart version (chart version)
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace the video recorder logging entry points in both the video container and node-container recording path, then inspect how SE_LOG_TIMESTAMP is read and applied elsewhere. Reproduce with the reported mixed log output and verify that video messages in both contexts use the configured timestamp format consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker
- Domain
- devops, observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100