action #97994
open
bot-ng - sometimes doesn't update smelt data in dashboard
Added by osukup over 3 years ago.
Updated over 3 years ago.
Description
see https://gitlab.suse.de/qa-maintenance/bot-ng/-/jobs/557971#L321
ERROR: Smelt Incidents wern't synced to dashboard
Acceptance criteria¶
- AC1: Incidents are always synced
Suggestions¶
- Make the error message useful
- Investigate why we have error 400
- Look at the dashboard side of it also
Work-around¶
- We trust the next pipline runs cover retry sufficiently
- Project changed from QA (public) to openQA Project (public)
- Target version set to Ready
- Project changed from openQA Project (public) to QA (public)
could be a good candidate for bot-ng first-time contributors.
- Assignee set to jbaier_cz
Please know that this ticket is not yet "Workable". If you consider the fix trivial, give it a try, otherwise please wait after we had a chance to estimate
- Subject changed from bot-ng - sometimes didn't update smelt data in dashboard to bot-ng - sometimes doesn't update smelt data in dashboard size:S
- Description updated (diff)
- Status changed from New to Workable
- Status changed from Workable to In Progress
- Due date set to 2021-10-01
Setting due date based on mean cycle time of SUSE QE Tools
- Due date deleted (
2021-10-01)
- Status changed from In Progress to Feedback
Job with new setup was successful. Last line is now a little bit more meaningful.
On the other hand, it looks like the retry is not helping at all in this case. We got error 400 from the dashboard. More investigation will be needed, if we want to find the source of this problem.
- Subject changed from bot-ng - sometimes doesn't update smelt data in dashboard size:S to bot-ng - sometimes doesn't update smelt data in dashboard
- Description updated (diff)
- Status changed from Feedback to New
- Assignee deleted (
jbaier_cz)
- Priority changed from Normal to Low
- Target version changed from Ready to future
The pipeline failed, and it wasn't a straight-forward fix
There are no errors in the dashboard journal, that hints at the 400 response coming from the nginx reverse proxy. Maybe it doesn't like a header in the request?
Since the HTTP response code is 400 Bad Request, a simple retry might not be enough. There's probably something wrong with the request. If the 400 response contained a response body, that's what we need to look at first.
Also available in: Atom
PDF