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 wrong timestamp format #338
fix wrong timestamp format #338
Conversation
@agrare @juliancheal please review |
👍 LTGM. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @AlexanderZagaynov we are trying to get away from event catchers having direct access to the database with the goal of moving these types of workers away from rails to reduce memory usage.
Handling duplicate events could probably be done in the Event Handler so it would apply to all providers.
Could we just move to the format_timestamp(1.minute.ago)
to fix the original issue?
Checked commits AlexanderZagaynov/manageiq-providers-azure@d5367d0~...31f7a6e with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0 |
@agrare done :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks Alex!
|
Yes to both |
…eceive_events fix wrong timestamp format (cherry picked from commit 6b90aaa) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1724312
Ivanchuk backport details:
|
…eceive_events fix wrong timestamp format (cherry picked from commit 6b90aaa) https://bugzilla.redhat.com/show_bug.cgi?id=1733383
Hammer backport details:
|
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1724312
Root issue was the wrond timestamp format in the first query to the Azure API since worker start.
Another potential issue could happen during that worker restart - if it lasts more than one minute. I extended it to 5 minutes and added a check to avoid duplicated events.