[MGNLBACKUP-105] Invoking backup via REST might be logged as success although it actually failed Created: 14/Oct/16  Updated: 29/Mar/22  Resolved: 04/Nov/16

Status: Closed
Project: Backup
Component/s: None
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.0, 2.1

Type: Bug Priority: Neutral
Reporter: Ilgun Ilgun Assignee: Ilgun Ilgun
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screen Shot 2016-10-31 at 15.09.28.png    
Issue Links:
Relates
relates to MGNLREST-62 Add possibility to put context attrib... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Sprint: Basel 69
Story Points: 5
Team: Nucleus

 Description   

Directly from the commit message:

  • Essentially before this commit, backup request's done via REST would simply always return true. This is due to v2 endpoint to rely on exception is being thrown. If no exception occurs, it assumes that command is successful. Therefore we have aligned BackupCommand with CommandsManager by simply returning 'false' when it is successful and throwing the exception when it fails.
  • Also trying to obtain stacktrace in the BackupLauncher so that user's will have the chance to track what went wrong if something goes wrong.
  • Throwing a RuntimeException by default at ObservationAwareBackupExecutor because it's possible to fail the backup request when something had changed meanwhile in the version workspace. If an exception really occurs this predefined exception will be overridden anyways. If the backup execution succeeds we will be returning 'false' and hence predefined exception will not be used.

Generated at Sun Feb 11 23:25:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.