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

bug: address parsing wavefront urls with a path component #109

Merged
merged 2 commits into from
Oct 24, 2022
Merged

bug: address parsing wavefront urls with a path component #109

merged 2 commits into from
Oct 24, 2022

Conversation

LukeWinikates
Copy link
Contributor

resolves: #108

This PR adds a "Path" field to the configuration struct so that we can stash the path component of a URL there and use it to correctly reconstruct a URL later.

I would be interested in suggestions about the MetricsURL and TracesURL methods; I think exporting these is a little bit unfortunate, but the url construction is important to test and is currently a little hard to exercise in a test because it's happening inside unexported functions. We could refactor to make this easier to test, but I didn't want to increase the scope of the PR for this fix.

This supports usecases where rather than talking to a WF instances or proxy directly, we are communicating through some sort of proxy that does path-based routing of our requests.

@keep94 @oppegard thanks in advance for your eyes on this PR 🙇‍♂️

cc: @rushikeshbgithub

Copy link
Contributor

@keep94 keep94 left a comment

Choose a reason for hiding this comment

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

Thanks for doing this work LukeWinikates. I just have a few suggestions.

return reporter.execute(req)
}

func linesToBuffer(pointLines string) (bytes.Buffer, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think bytes.Buffer supports copying by simple assignment. Instead of returning a bytes.Buffer or even a *bytes.Buffer consider instead returning a []byte. Returning a []byte is more concise and less confusing because you are eagerly constructing the bytes in this function anyway. Also consider renaming linesToBuffer to linesToBytes or something like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think what you're saying is that returning a bytes.Buffer is a form of copying by value and that the buffer might not end up containing the intended gzipped content. I haven't dug into that but I like the idea of returning the simpler []byte type - pushing that change now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Slightly concerned about whether the refactor, although more readable, might cause any noticeable performance changes given we're creating a new buffer twice now (I don't know if we think of this code as performance sensitive or have any performance tests around it)

Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding your concern about creating a buffer twice. The godocs for NewBuffer say: NewBuffer creates and initializes a new Buffer using buf as its initial contents. The new Buffer takes ownership of buf, and the caller should not use buf after this call. This makes me think that the new Buffer is using the existing slice for its storage which should be relatively cheap.

internal/reporter.go Outdated Show resolved Hide resolved
internal/reporter.go Outdated Show resolved Hide resolved
senders/client_factory.go Outdated Show resolved Hide resolved
Copy link
Contributor

@keep94 keep94 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 To Me

@keep94 keep94 merged commit 3c036f3 into wavefrontHQ:master Oct 24, 2022
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.

bug: senders.NewSender does not support urls with both port and path.
3 participants