fix: handle default columns in logs and traces explorer

[YounixM]

Root Cause Analysis: Logs Columns Applied in Traces Explorer

Problem

Sometimes default column options from Logs Explorer (timestamp, body) are incorrectly applied in Traces Explorer, causing query failures because Traces queries don't support Logs-specific columns.

Root Cause

Issue 1: Shared URL Parameter Without Validation

The options URL parameter is shared between Logs and Traces explorers. When navigating from Logs to Traces, the URL may still contain Logs columns. The tracesLoaderConfig.url() loader accepts any columns from the URL without validating they're valid for Traces.

Flow:

1. User in Logs Explorer: /logs?options={"selectColumns":[{"name":"body","signal":"logs"},...]}
2. User navigates to Traces Explorer
3. URL still contains: /traces?options={"selectColumns":[{"name":"body","signal":"logs"},...]}
4. tracesLoaderConfig.url() reads columns from URL → finds columns with length > 0
5. preferencesLoader uses URL columns (priority: ['local', 'url', 'default'])
6. Traces Explorer tries to query with Logs columns → Query fails

Issue 2: localStorage Contamination

Similar issue with localStorage - if TRACES_LIST_OPTIONS contains Logs columns (from corruption or incorrect storage), they're loaded without validation.

Issue 3: Incorrect Default Columns in View Selection

The updateOrRestoreSelectColumns function in ExplorerOptions.tsx always used defaultTraceSelectedColumns regardless of the current data source, causing incorrect fallback behavior.

Solution

Fix 1: Column Validation in Loaders

Added validation in tracesLoaderConfig.ts to filter out invalid columns:

• Reject columns with signal !== 'traces'
• Reject known Logs-only columns (body)
• Reject timestamp with signal='logs'
• Return empty array if no valid columns, triggering fallback to defaults

Fix 2: Correct Default Columns Based on Data Source

Updated updateOrRestoreSelectColumns to use the correct default columns based on sourcepage:

• Traces Explorer → defaultTraceSelectedColumns
• Logs Explorer → defaultLogsSelectedColumns

Impact

• ✅ Prevents query failures in Traces Explorer
• ✅ Ensures correct column defaults per explorer
• ✅ Prevents cross-contamination between Logs and Traces preferences
• ✅ Maintains backward compatibility

Testing

• Unit tests added to verify column filtering
• Manual testing scenarios documented
• Edge cases covered (mixed columns, missing signal, etc.)

[aks07]

We need to add a similar filter for logsLoaderConfig as well as the issue is on that page as well.

[aks07]

This is not needed. We can filter only based on col signal being traces

[aks07]

We need this filtering for logs as well

[aks07]

Logs version of the issue

[aks07]

Adding to the root cause, this happens when either logs or traces don’t have configuration stored in localStorage, but options are present in the URL. Since preferences are set once on load, if the traces page is loaded first, it will apply the trace options to the logs preferences as well, because no default preference for logs exists in localStorage. The same issue occurs in reverse.

The solution is to filter columns based on the signal when setting preferences in the scenario described above.

One more thing to keep in mind is that preferences are set only on the first load. This isn’t an issue now, but it may need to be reconsidered in the future if the scope expands.