fix(app): negative duration in search

[mark-omarov]

Closes #15

Proposed change:
Display "N/A" instead of negative numbers for columns not supporting the duration property.

Alternatives considered:

• Update APIs to return null or omit the field - it would still require changes on the UI
• Change the DB model to use null or 0 as a value when end_timestamp is missing - requires a DB migration for all existing users, probably not a good idea
• Reformat data on the API response in the useSearchEventStream - complicates already complicated hook, plus the LogTable component already had to use the accessorFn, might as well use it

[changeset-bot]

🦋 Changeset detected

Latest commit: ee3e6a3

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

This PR includes changesets to release 1 package

Name	Type
@hyperdx/app	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

[mark-omarov]

The issue is going to be resolved differently, as mentioned in the #15

[wrn14897]

Hey @mark-omarov ,

If you are still interested, we'd love to get this fix out.
We still want to keep the current behavior on the ingestor side and the way we think about duration field for logs (should be nullable).
Thanks for contributing to the repo 🙏

[MikeShi42]

Looks awesome! It's good to merge as-is.

I have two minor suggestions we can do later if you'd like:

1. It'd be awesome if the value is N/A, that we assign the class as text-muted so it's less distracting in the UI.
2. I think null might work better than N/A in the UI, since it is technically null (though I know in the DB it isn't actually nullable, due to performance reasons)

[MikeShi42]

optional nit: we don't have any tree-shaking for lodash built in the build chain so it'd be preferable to do import curry from lodash/curry. However, we already import all of lodash in a few other components and it needs to be made consistent across the entire code base.

We can merge this as-is, since we're already inconsistent, and I made a follow-up issue addressing the broader issue in our code base #36

[mark-omarov]

Thanks for taking a look! I just pushed the update
I could work on #36 as well, if you don't mind

[mark-omarov]

@MikeShi42 I went ahead and opened an issue based on your comment to make things better down the line. Hope that's cool with you. Ref: #37

[MikeShi42]

Thank you for #37! And it looks like someone already jumped on #36 with a PR (#38)

[MikeShi42]

Looks awesome, thank you! 😄