Skip to content
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

Block trace on more query results #21826

Merged
merged 4 commits into from
May 14, 2024
Merged

Conversation

Comment on lines 95 to 96
React.useCallback(async () => {
await Promise.all([querySensor(), querySensorAssetSelection()]);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this particular bit do anything? Does the delayed row query have tracing built into it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah no, forgot to remove this

Comment on lines 323 to 326
if (hasMore) {
startPolling(POLL_INTERVAL);
} else {
dependency.completeDependency(CompletionType.SUCCESS);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is correct - it means that if a run is in progress and we start polling for logs here, we will not mark the page as loaded until the run completes?

variables: {snapshotId},
});

const {data, loading} = queryResult;
useBlockTraceOnQueryResult(queryResult, 'SnapshotQuery');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like most of the time, if you skip this line, you are messing up the datadog traces...

I think it'd be worth evaluating whether a different design would make this less fragile - wrapping useQuery itself like we talked about, or making our three <Loading /> components block the trace, etc.

Just seems like this will almost certainly be broken in subtle ways 12mo from now unless we're vigilant about testing the datadog output of new pages. If we need to do it this way, maybe we could add a visual indicator on the page in dev that shows you what the datadog trace status is. (eg: an actual dot that goes from red to green when the dd trace is loaded, so you can verify it matches your loading states)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just seems like this will almost certainly be broken in subtle ways 12mo from now unless we're vigilant about testing the datadog output of new pages. If we need to do it this way, maybe we could add a visual indicator on the page in dev that shows you what the datadog trace status is. (eg: an actual dot that goes from red to green when the dd trace is loaded, so you can verify it matches your loading states)

Yeah 100% agree. I think a visual indicator is a great idea.

@salazarm salazarm merged commit 935a0f0 into master May 14, 2024
1 of 2 checks passed
@salazarm salazarm deleted the salazarm/block-on-more-query-results branch May 14, 2024 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants