feat: Include displayed timestamp in default order by

[pulpdrew]

Closes HDX-2593

This PR adds a source's displayedTimestampValueExpression (if one exists) to the default order by on the search page.

In schemas like our default otel_logs table, there are two timestamp columns: TimestampTime DateTime (1-second precision) and a Timestamp DateTime64(9) (nanosecond precision). TimestampTime is preferred for filtering because it is more granular and in the primary key. However, ordering by TimestampTime alone results in an arbitrary order of events within each second:

The HyperDX source configuration form already supports configuring a 'Displayed Timestamp Column" for a log source. This PR adds the same option for Trace sources. This field is inferred from the otel logs and traces schemas as Timestamp.

If the source has a displayed timestamp column configured, and if this column is different than the source's timestamp value expression, then this field will be added to the default order by which is generated for the search page. This results in a more precise ordering of the events in the logs table within each second:

[changeset-bot]

🦋 Changeset detected

Latest commit: 7445bbf

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@hyperdx/app	Patch
@hyperdx/api	Patch

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

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
hyperdx-v2-oss-app	Ready	Preview	Comment	Oct 17, 2025 7:02pm

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

[pulpdrew]

This field was already being inferred for the default OTEL trace table, now we allow the user to modify it if needed.

[claude]

PR Review

✅ No critical issues found.

Code Quality Notes:

The implementation looks solid. The logic correctly:

• Adds displayed timestamp to ORDER BY when it differs from primary timestamp
• Handles edge cases (empty strings, whitespace, duplicate expressions)
• Preserves existing sorting keys when they contain the displayed timestamp
• Includes comprehensive test coverage with 15+ test cases

Minor observations (non-blocking):

• Good defensive coding with trim() to handle whitespace
• Test coverage is thorough and covers edge cases well
• Follows existing patterns in the codebase (consistent with optimizeDefaultOrderBy logic)

The changeset and documentation updates are appropriate for this feature.

[github-actions]

E2E Test Results

✅ All tests passed • 26 passed • 3 skipped • 249s

Status	Count
✅ Passed	26
❌ Failed	0
⚠️ Flaky	0
⏭️ Skipped	3

View full report →

[brandon-pereira]

Maybe its a bug maybe not,but the timestamp column gets changed when sorting

Screen.Recording.2025-10-17.at.3.39.37.PM.mov

[pulpdrew]

Maybe its a bug maybe not, but the timestamp column gets changed when sorting

That's a good point. Though it seems that the default order by is restored if the user clicks on the table header again to unsort by the column. And this is existing behavior whenever the default order by is not the Timestamp column (which is almost always for log sources, since the timestamp column is typically TimestampTime and optimized schema will often have a default order by something like toStartOfMinute(TimestampTime), TimestampTime.

I think the solution would be to determine if the user is clicking on a timestamp-type column which is included in the default order by, and in that case override the selected sort column with the default optimized order by. That could be a good enhancement.