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

Investigate possible issue on handling the response for delta submission #843

Open
cristianciutea opened this issue Nov 23, 2021 · 0 comments
Assignees
Labels
accepted-jira priority/long-term Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@cristianciutea
Copy link
Contributor

cristianciutea commented Nov 23, 2021

In the delta store.go, we handle the response from the platform on delta submission.
There are different scenarios when the platform can reject the deltas, providing a hint on fixing the issue.
The is a case when platform expected a delta ID that is higher with 1 than the one sent.
During an investigation, I've noticed that the delta cache file is not updated in this case. (the file is updated by calling SaveState method).
We should check why this is happening and if it's expected (the comment in the code states that is the "normal case", so maybe is the expected behavior). Also we should sync with the platform to see if we should save the "id" or the "SendNextID"

current code:

case resultHint.SendNextID == id+1:
			// Normal case.
			p.setLastSentID(entityKey, id)

Steps to reproduce:

  • clean /var/db/newrelic-infra/data directory
  • (optional) clean logs
  • Change the display_name to a new one, so a new entityID is created in the platform
  • Start the agent and tail the logs. You can grep by 'hint.'
  • Check the delta /var/db/newrelic-infra/data/.delta_repo/delta_id_cache.json file and see if last_sent_id has been updated
@davidgit davidgit added bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Nov 23, 2021
@rogercoll rogercoll self-assigned this Dec 17, 2021
@davidgit davidgit added the priority/long-term Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Jan 4, 2022
@josemore josemore added accepted-jira and removed bug Categorizes issue or PR as related to a bug. labels Sep 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted-jira priority/long-term Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

4 participants