-
Notifications
You must be signed in to change notification settings - Fork 518
feat: add session filtering and filter condition support to backend GraphQL APIs #9009
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: add session filtering and filter condition support to backend GraphQL APIs #9009
Conversation
…raphQL resolvers - Add session_filter parameter to trace_count, cost_summary, and latency_ms_quantile resolvers - Add filter_condition parameter to trace_count and latency_ms_quantile resolvers - Add _apply_session_io_filter utility function for reusable session filtering logic - Resolvers now support filtering by span conditions and session I/O content
- Update record_counts, span_cost_summary_by_project, and latency_ms_quantile dataloaders - Add session_filter parameter to dataloader type definitions and cache keys - Implement session filtering logic in dataloader query statements - Add span filter support for trace-level queries (traces containing matching spans)
- Add session_filter=None parameter to existing dataloader test keys - Ensures backward compatibility with existing test data structures
- Add test_trace_count_with_span_filter_returns_correct_data to verify span filtering works - Add test_cost_summary_with_session_filter_returns_filtered_data to verify session filtering - Add test_latency_quantile_with_filters_returns_accurate_percentiles to verify quantile filtering - Tests ensure filtered results differ from unfiltered results as expected
Previously when applying a span filter condition to count traces, the query would count all matching spans rather than distinct traces. This caused inflated trace counts when multiple spans per trace matched the filter. The fix changes the query from: - count(*) with DISTINCT on the entire result to: - count(DISTINCT traces.id) without the problematic .distinct() on the join This ensures each trace is counted only once, regardless of how many spans within that trace match the filter condition.
Add session_filter parameter to span_annotation_summary GraphQL resolver and implement session filtering logic in annotation_summaries dataloader. Includes session I/O filtering for UUID and substring search patterns, maintaining backward compatibility with existing functionality.
CLA Assistant Lite bot: I have read the CLA Document and I hereby sign the CLA You can retrigger this bot by commenting recheck in this Pull Request |
I will add the frontend in a follow up to this, pending any feedback here. I wanted to keep the PR size down. |
return stmt.join(models.ProjectSession).where( | ||
models.ProjectSession.session_id == session_filter | ||
) | ||
else: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: UUID Validation and Access Control Flaws
The _apply_session_io_filter
function has two related issues. First, its UUID validation regex r"^[0-9a-f-]{36}$"
is overly permissive, matching any 36-character string of hex digits and hyphens instead of enforcing the standard UUID format. This can cause non-UUID strings to be incorrectly treated as session IDs. Second, when a string is identified as a UUID (either correctly or incorrectly due to the permissive regex), the subsequent session_id
filter lacks a project_rowid
check, potentially allowing access to sessions from other projects.
Backend component for #9008
This PR implements backend GraphQL API support for session filtering and filter conditions across header metrics, enabling filtered trace counts, cost summaries, latency, quantiles, and annotation summaries.
The implementation adds sessionFilter and filterCondition parameters to Project type resolvers and updates all relevant dataloaders to accept and apply these filters. SQL queries have been enhanced to properly handle session-based filtering and span filter conditions, with unit tests added to cover all filtering scenarios.