Handle empty event response #70
Conversation
|
@sarita-maersk thanks for your contribution, I never see that behavior in our clusters, in documentation that also never been mention. But if you see that errors in real life - agree, seems that we needed that changed. How frequently you see that error in your clusters? What about raise log level to There are some linter issue, please fix that. |
|
Thank you @maksim-paskal for the quick review. Please find my response inline.
We run ~350 spot nodes in our telemetry cluster and the frequency of this error ranges from 
Since Azure document doesn't mention anything about empty response, I am in favour of making this log level to
Fixed. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #70 +/- ##
=======================================
Coverage 98.53% 98.53%
=======================================
Files 6 6
Lines 205 205
=======================================
Hits 202 202
Misses 2 2
Partials 1 1 ☔ View full report in Codecov by Sentry. |
|
@sarita-maersk, your changes were released. I also added debug logs for requests in the new release. This can help us debug other responses that aren't well-documented in the future. Thank for your contribution! |
3 participants
Currently when there are no events scheduled for a node, the endpoint
curl -H Metadata:true http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01Scenario-1
Scenarioa-2
In our Azure nodes, the termination handler has been exclusively logging
json unmarshal errorsas the node's scheduled events response is empty.{ "error": "error in json.Unmarshal: unexpected end of JSON input", "level": "error", "msg": "", "time": "2024-01-30T15:27:06Z" }Receiving empty response from the scheduled events endpoint is a valid scenario, we should not treat this as an error. In this PR we are logging the required message at info level and returns no error if the response body is empty.