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

fix: correctly use controller when registering interest and correctly use node's ID when publishing metrics. #3273

Merged
merged 4 commits into from
Jul 31, 2024

Conversation

nathanielc
Copy link
Contributor

Description

In testing the node metrics publish I found two bugs:

  1. Metrics interest was for all peers not just itself.
  2. The node id was empty causing the published data to fail validation.

This fixes both issues.

The controller needs to be a query parameter not a POST body object.

The ipfsId.publicKey was empty I do not know why, however the ipfsId.id field was set correctly and works as expected.

How Has This Been Tested?

Manually tested, starting a node. Previously the node saw errors everytime it tried to publish metrics. Additionally I directly inspected the interest and was able to see it was for all controllers not just itself. I have manually verified the interest is now for the specific controller.

PR checklist

Before submitting this PR, please make sure:

  • I have tagged the relevant reviewers and interested parties
  • I have updated the READMEs of affected packages
  • I have made corresponding changes to the documentation

References:

Please list relevant documentation (e.g. tech specs, articles, related work etc.) relevant to this change, and note if the documentation has been updated.

@nathanielc nathanielc requested review from gvelez17 and stbrody July 30, 2024 16:15
@@ -169,11 +169,10 @@ export class ReconApi extends Observable<ReconEventFeedResponse> implements IRec
}
try {
const headers = { 'Content-Type': 'application/json' }
const body = { ...(controller && { controller }) }
await this.#sendRequest(this.#url + `/ceramic/interests/model/${model.toString()}`, {
const query = controller ? `controller=${controller}` : ''
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do we have a canonical way of constructing query strings for URLs? This string manipulation is not ideal.

const body = { ...(controller && { controller }) }
await this.#sendRequest(this.#url + `/ceramic/interests/model/${model.toString()}`, {
const query = controller ? `controller=${controller}` : ''
await this.#sendRequest(this.#url + `/ceramic/interests/model/${model.toString()}?${query}`, {
Copy link
Contributor

Choose a reason for hiding this comment

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

huh, should this be considered an issue with the API that C1 is exposing? This is a POST request, why is it using URL query parameters instead of taking its args in the POST body? Maybe the thing to do is change it in C1 instead of here?

CC @dav1do

Copy link
Contributor

Choose a reason for hiding this comment

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

ah, yeah. that's actually the old one.. we have a newer one POST /interests that behaves 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.

Query params are not exclusive to get requests. I don't have a strong opinion either way just updated the client to match the server.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dav1do Thanks for the link to the new endpoint. I changed the code to use the new endpoint and manually tested. Working well...

Base automatically changed from wait-for-model-aes-232-new-approach to develop July 30, 2024 20:58
@nathanielc nathanielc requested review from stbrody and dav1do July 31, 2024 14:34
@nathanielc nathanielc force-pushed the fix/node-metrics-publish-bugs branch from 103e198 to e3b5ba0 Compare July 31, 2024 15:02
@nathanielc nathanielc merged commit e719816 into develop Jul 31, 2024
7 checks passed
@nathanielc nathanielc deleted the fix/node-metrics-publish-bugs branch July 31, 2024 17:50
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.

3 participants