-
Notifications
You must be signed in to change notification settings - Fork 63
Report failed downloads in an installation report. #1301
Report failed downloads in an installation report. #1301
Conversation
1d59acf
to
affb28f
Compare
Don't we just need to fake some http error code with HttpFake or some or our python http scripts? |
Codecov Report
@@ Coverage Diff @@
## master #1301 +/- ##
==========================================
- Coverage 79.05% 78.97% -0.08%
==========================================
Files 178 178
Lines 10475 10494 +19
==========================================
+ Hits 8281 8288 +7
- Misses 2194 2206 +12
Continue to review full report at Codecov.
|
Oooh, nice idea. I was already halfway through setting up libfiu. I'll take that under consideration as well. |
Fixed with tests using libfiu after all. It wasn't hard and the additional power is nice to have. |
What do you mean here? director would need at least the correlation id to make this work..
|
Correlation ID is included. I just mean the error code/message is fairly generic. I've tested manually and it works, but the UI says:
|
This should inform the Director that the update failed. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Otherwise this prevents being able to split updates into multiple individual calls to the Install API call. This still isn't my favorite fix for this problem, but in the short term, it's an improvement. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
This is not an ideal solution! This makes it impossible to retry downloading via the API without setting up another update in the Director and rechecking for updates. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
adbc70f
to
636acdb
Compare
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.
Tests:
- Device is not stuck after failed download - ok
- Device can install new updates after failed download - ok
- Creating devices and installing updates on them - ok
// Store installation report to inform Director of the download failure. | ||
const std::string &correlation_id = director_repo.getCorrelationId(); | ||
data::InstallationResult device_installation_result = | ||
data::InstallationResult(data::ResultCode::Numeric::kDownloadFailed, "Target download failed"); |
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.
As far as I understand the mechanism of cancelling/removing of the new targets at Director is a sending manifest to it with a negative installation result in case if all targets downloads fails ?
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.
If I'm understanding you correctly, yes. If we send an installation report with a failure code, the Director will respond by identifying the installation as a failure, and subsequent Targets metadata will be empty (to indicate that the device should take no further action, i.e. not retry until explicitly told to do so). Let me know if that doesn't make sense or you have further questions.
This should inform the Director that the update failed.
This appears to fix the bug, but it is not perfect:
There is no test, because we don't have a way to fake a download failure. It's probably doable with libfiu and the fake package manager, though.This is now covered by tests.could behas been handled the same way,althoughdespite that I don't like the solution of dropping metadata.We might want to consider merging testing and merging this as is anyway just to get the fix out the door, but further consideration is necessary to address the above issues.