Skip to content

Fix: skip opentelemetry-instrument when OTEL is disabled#2968

Merged
gantoine merged 1 commit intorommapp:masterfrom
Wadenschwinger:fix/watcher-otel-disabled-env-passthrough
Jan 31, 2026
Merged

Fix: skip opentelemetry-instrument when OTEL is disabled#2968
gantoine merged 1 commit intorommapp:masterfrom
Wadenschwinger:fix/watcher-otel-disabled-env-passthrough

Conversation

@Wadenschwinger
Copy link
Copy Markdown
Contributor

@Wadenschwinger Wadenschwinger commented Jan 30, 2026

Description

When OTEL_SDK_DISABLED=true (set automatically when no OTEL_ env vars are present), the opentelemetry-instrument wrapper does not pass through the WATCHFILES_CHANGES environment variable to watcher.py.

This causes the filesystem watcher to silently fail: watchfiles detects changes but watcher.py receives an empty WATCHFILES_CHANGES and exits immediately without scheduling rescans.

The fix: Skip the opentelemetry-instrument wrapper when OTEL is disabled, allowing watchfiles to pass WATCHFILES_CHANGES directly to watcher.py.

This fixes ENABLE_RESCAN_ON_FILESYSTEM_CHANGE=true for users who don't configure OpenTelemetry.

Checklist

  • I've tested the changes locally
  • I've updated relevant comments
  • I've assigned reviewers for this PR
  • I've added unit tests that cover the changes

Screenshots (if applicable)

Before fix (watcher exits immediately, no rescan scheduled):

[22:49:51] 1 change detected
[22:49:51] process already dead, exit code: 0

After fix (watcher processes changes and schedules rescan):

[22:49:51] 1 change detected
INFO: [RomM][watcher] Filesystem event: added /roms/gba/test.txt
INFO: [RomM][watcher] Change detected in gba folder, rescanning in 2 minutes.

When OTEL_SDK_DISABLED=true (set automatically when no OTEL_ env vars
are present), the opentelemetry-instrument wrapper does not properly
pass through the WATCHFILES_CHANGES environment variable to watcher.py.

This causes the filesystem watcher to silently fail - watchfiles detects
changes but watcher.py receives an empty WATCHFILES_CHANGES and exits
immediately without scheduling any rescans.

The fix skips the opentelemetry-instrument wrapper when OTEL is disabled,
allowing watchfiles to pass WATCHFILES_CHANGES directly to watcher.py.

Fixes automatic rescan on filesystem change for users who don't configure
OpenTelemetry (the majority of self-hosted deployments).
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @Wadenschwinger, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue affecting the filesystem watcher's ability to detect and respond to file changes when OpenTelemetry is not configured. By introducing a conditional bypass for the opentelemetry-instrument wrapper, the WATCHFILES_CHANGES environment variable is now correctly propagated to watcher.py, ensuring that automatic rescans function as expected for all users, particularly those in self-hosted environments without OpenTelemetry setup.

Highlights

  • Filesystem Watcher Fix: Addressed a bug where the opentelemetry-instrument wrapper prevented the WATCHFILES_CHANGES environment variable from being properly passed to watcher.py when OpenTelemetry was disabled.
  • Silent Failure Resolution: This issue previously caused the filesystem watcher to fail silently, leading to watcher.py receiving an empty WATCHFILES_CHANGES and exiting without scheduling rescans.
  • Conditional Instrumentation Bypass: Implemented a conditional check for OTEL_SDK_DISABLED=true to bypass the opentelemetry-instrument wrapper, allowing watchfiles to directly invoke python3 watcher.py.
  • Improved Reliability for Self-Hosted Deployments: Ensures automatic rescans on filesystem changes now function correctly for users who do not configure OpenTelemetry, which is crucial for the majority of self-hosted deployments.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a bug where the filesystem watcher would silently fail when OpenTelemetry is disabled. The proposed fix correctly bypasses the opentelemetry-instrument wrapper when OTEL_SDK_DISABLED is true, ensuring the WATCHFILES_CHANGES environment variable is passed correctly. The change is correct and well-justified. I've added one suggestion to refactor the new code to reduce duplication and improve maintainability.

Copy link
Copy Markdown
Member

@gantoine gantoine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏼

@gantoine gantoine merged commit 73d8c64 into rommapp:master Jan 31, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants