Skip to content

Conversation

@devin-ai-integration
Copy link
Contributor

Fix: Respect CREWAI_DISABLE_TELEMETRY for tracing requests

Summary

Fixes issue #3907 where HTTP requests to /crewai_plus/api/v1/tracing/ephemeral/batches were still being made despite CREWAI_DISABLE_TELEMETRY=true being set in the environment.

The root cause was that the tracing system (TraceBatchManager and TraceCollectionListener) was separate from the telemetry system and didn't check the CREWAI_DISABLE_TELEMETRY environment variable. This PR implements a defense-in-depth approach:

  1. Added is_tracking_disabled() helper in utils.py that checks both CREWAI_DISABLE_TELEMETRY and CREWAI_DISABLE_TRACKING environment variables
  2. Added guards in TraceBatchManager to prevent network calls in:
    • _initialize_backend_batch() - returns early
    • _send_events_to_backend() - returns 200 to avoid error paths
    • finalize_batch() - returns None early
    • _finalize_backend_batch() - returns early
  3. Added guards in TraceCollectionListener to prevent listener registration:
    • __init__() - returns early to skip initialization overhead
    • setup_listeners() - returns early to avoid registering event handlers
  4. Added comprehensive test coverage with 19 tests covering both disabled and enabled scenarios, including parametrized tests for different env var values and both ephemeral and non-ephemeral code paths

Review & Testing Checklist for Human

  • Critical: Verify the fix works end-to-end - Set CREWAI_DISABLE_TELEMETRY=true in a real crew execution and confirm via network monitoring (tcpdump, Wireshark, or proxy logs) that NO requests are made to /crewai_plus/api/v1/tracing/ephemeral/batches
  • Verify return value semantics - Check that returning 200 from _send_events_to_backend() when disabled doesn't cause unexpected behavior in calling code (it's meant to avoid error paths that would call mark_trace_batch_as_failed())
  • Test both environment variables - Verify that both CREWAI_DISABLE_TELEMETRY=true and CREWAI_DISABLE_TRACKING=true work as expected
  • Check for missed code paths - Review if there are any other entry points to the tracing system that might bypass these guards
  • Singleton edge cases - Verify that TraceCollectionListener's singleton behavior works correctly when the env var is toggled (though this is an unlikely scenario in production)

Test Plan

  1. Create a simple crew with a task
  2. Set CREWAI_DISABLE_TELEMETRY=true in environment
  3. Run the crew with network monitoring enabled
  4. Verify NO HTTP requests are made to CrewAI Plus API endpoints
  5. Repeat with CREWAI_DISABLE_TRACKING=true to verify it also works
  6. Run without the env var to confirm tracing still works normally when enabled

Notes

- Add is_tracking_disabled() helper function to check CREWAI_DISABLE_TELEMETRY and CREWAI_DISABLE_TRACKING
- Add guards in TraceBatchManager to prevent network calls when tracking is disabled
- Add guards in TraceCollectionListener to prevent listener registration when tracking is disabled
- Add comprehensive tests covering both disabled and enabled scenarios
- Fixes issue #3907 where telemetry requests were still being made despite CREWAI_DISABLE_TELEMETRY=true

Co-Authored-By: João <joao@crewai.com>
@devin-ai-integration
Copy link
Contributor Author

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

  • Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
  • Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

  • Disable automatic comment and CI monitoring

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