Skip to content

Conversation

@tjhop
Copy link
Contributor

@tjhop tjhop commented Dec 15, 2025

Two small fixes:

  • I forgot the implementation for *apiClientImpl.Do() already extracts
    the response content from the enveloped data field in the response,
    so the wrapper struct isn't needed here.
  • The compaction section of a block has an optional parents field
    for tracking block lineage in deeper compaction levels. This slipped
    my mind during implementation because I was looking at the example API
    response on the API docs, which use a mock response with a single block
    that is uncompacted.

I noticed these while working on tjhop/prometheus-mcp-server#77

Signed-off-by: TJ Hoplock [email protected]

Two small fixes:

- I forgot the implementation for `*apiClientImpl.Do()` already extracts
  the response content from the enveloped `data` field in the response,
so the wrapper struct isn't needed here.
- The `compaction` section of a block has an optional `parents` field
  for tracking block lineage in deeper compaction levels. This slipped
my mind during implementation because I was looking at the example API
response on the API docs, which use a mock response with a single block
that is uncompacted.

I noticed these while working on tjhop/prometheus-mcp-server#77

Signed-off-by: TJ Hoplock <[email protected]>
Copy link
Member

@kakkoyun kakkoyun left a comment

Choose a reason for hiding this comment

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

Considering these issues slipped through the cracks, I would really appreciate if you could add more comprehensive tests so that we prevent similar future issues.

Thanks in advance 🙏

@tjhop
Copy link
Contributor Author

tjhop commented Dec 15, 2025

That's fair, I can expand tests.

Ideally, it would be simpler to just import prometheus itself as a library and use the types already defined for these in prometheus. That would obviously help to keep things in sync and benefit from existing testing there. It becomes a bit awkward though, since prometheus itself also imports the client_golang library (mostly for implementing metrics) and so we'd be importing ourselves and nearing a circular import. It would also blow up dependencies, and I know this library is already heavily used/strictly watched for deps.

Perhaps this is a situation where a little bit of copying is better than a little bit of dependency?

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