fix(dashboard): use exact server filtering in logs#1984
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 0c6c2ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| const attrLogsQuery = useLogsEnabledErrorCheck( | ||
| useAttributeLogsQuery({ | ||
| logFilters, | ||
| extraFilters: serverFilters, | ||
| gramUrn: effectiveGramUrn, | ||
| from, | ||
| to, | ||
| enabled: hasLogFilters, | ||
| enabled: hasStructuredFilters, | ||
| }), | ||
| ); |
There was a problem hiding this comment.
🚩 Server-only filter now uses searchLogs API instead of searchToolCalls
When a server is selected without any attribute filters, the old code stayed on the toolCallsQuery (backed by telemetrySearchToolCalls API) with a URN prefix. The new code switches to attrLogsQuery (backed by telemetrySearchLogs API) whenever a server is selected. This is a change in which backend endpoint is hit for server-only filtering. The attrLogsQuery path involves client-side grouping of logs into trace summaries via logsToTraceSummaries (use-attribute-logs-query.ts:27-84), which is heavier than letting the server do grouping. If the server-side endpoint could support the gram.toolset.slug filter directly, it would be more efficient. This is worth noting but not a bug — it's a correctness-over-performance tradeoff.
Was this helpful? React with 👍 or 👎 to provide feedback.
Summary
Testing
client/dashboarddependencies are not installed in this worktree, sopnpm run type-checkcould not run)