Skip to content

Structure, refactor and clean up trace messages #751

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

Merged
merged 3 commits into from
Jul 1, 2025

Conversation

jorisdral
Copy link
Collaborator

@jorisdral jorisdral commented Jun 3, 2025

See the commit messages

I'm unsure whether 0abae6b is useful, so let me know if we should include it or not.

@jorisdral jorisdral self-assigned this Jun 3, 2025
@jorisdral jorisdral marked this pull request as draft June 3, 2025 15:48
@jorisdral jorisdral force-pushed the jdral/trace-messages branch 8 times, most recently from ff9b0df to 0abae6b Compare June 4, 2025 12:22
@jorisdral jorisdral changed the title Clean up trace datatypes Structure, refactor and clean up trace messages Jun 4, 2025
@jorisdral jorisdral marked this pull request as ready for review June 4, 2025 12:23
jorisdral added 3 commits July 1, 2025 10:33
We give the trace message datatypes more structure (see the `$traces` Haddock
section), and we add few new messages. In the process, we apply some minor
refactorings to tracer calls and surrounding code.
The idea is to cover as much of the public API as possible to trace most (if not
all) unique trace messages at least once. The trace output is useful in two
ways:

* By using golden tests based on the trace output we can help to ensure that
  trace datatypes and their printing do not change unexpectedly.

* The trace output serves as an example that can be manually inspected to see
  whether the trace messages are printed correctly and whether they are useful.
This helps troubleshoot golden test failures that can't be reproduced locally.
For example, if a golden test fails on a Windows machine, then I can not
reproduce it locally on an Ubuntu machine.
@jorisdral jorisdral force-pushed the jdral/trace-messages branch from 0abae6b to 22d4997 Compare July 1, 2025 08:52
Copy link
Collaborator

@dcoutts dcoutts left a comment

Choose a reason for hiding this comment

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

Looks good, including the CI action to upload golden test outputs.

There's just one bit I don't get, see below.

, sessionTracer :: !(Tracer m LSMTreeTrace)
sessionState :: !(RWVar m (SessionState m h))
, lsmTreeTracer :: !(Tracer m LSMTreeTrace)
, sessionTracer :: !(Tracer m SessionTrace)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do we add the sessionTracer here, separate from the LSMTreeTrace one? Below we don't seem to use it, we pass in a tr and locally construct a sessionTracer, like

  where
    sessionTracer = TraceSession (SessionId dir) `contramap` tr

Copy link
Collaborator Author

@jorisdral jorisdral Jul 1, 2025

Choose a reason for hiding this comment

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

We use lsmTreeTracer in duplicate, for example. We can't trace a TableTrace given a Tracer m SessionTrace, we need the Tracer m LSMTreeTrace

@jorisdral jorisdral added this pull request to the merge queue Jul 1, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 1, 2025
@jorisdral jorisdral added this pull request to the merge queue Jul 1, 2025
Merged via the queue into main with commit 53e7eab Jul 1, 2025
30 checks passed
@jorisdral jorisdral deleted the jdral/trace-messages branch July 1, 2025 13:13
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.

2 participants