Skip to content
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 workspace not opening if a recovery file has been corrupted #37178

Merged
merged 2 commits into from May 2, 2024

Conversation

jhaigh0
Copy link
Contributor

@jhaigh0 jhaigh0 commented Apr 17, 2024

Description of work

If a recovery file (.recfile file which holds a JSON object detailing workspace names, plot parameters, and open interfaces) is somehow corrupted, workbench was crashing as it set up the project recovery widget. I'm not sure how to recreate the corruption naturally, but I did have it happen to me where it was only half written out, maybe from a very badly timed force quit?

Summary of work

I've just added a try except around the read to catch a decode error and print a warning. The load_workspaces.py could still be perfectly usable, so the user can try and run this recovery regardless.

Fixes #37175

To test:

  • Follow the steps I wrote in the issue
  • The recovery checkpoint will appear in the widget as having 0 workspaces to recovery and a warning will be output
  • Running the recovery will still run the ordered_recovery.py script to recreate any lost workspaces

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

  • Is the code of an acceptable quality?
  • Does the code conform to the coding standards?
  • Are the unit tests small and test the class in isolation?
  • If there is GUI work does it follow the GUI standards?
  • If there are changes in the release notes then do they describe the changes appropriately?
  • Do the release notes conform to the release notes guide?

Functional Tests

  • Do changes function as described? Add comments below that describe the tests performed?
  • Do the changes handle unexpected situations, e.g. bad input?
  • Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

@jhaigh0 jhaigh0 added Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing) ISIS Team: Core Issue and pull requests managed by the Core subteam at ISIS labels Apr 17, 2024
@jhaigh0 jhaigh0 added this to the Release 6.10 milestone Apr 17, 2024
@jclarkeSTFC jclarkeSTFC self-assigned this May 2, 2024
Copy link
Contributor

@jclarkeSTFC jclarkeSTFC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug fixed

@robertapplin robertapplin merged commit e83fb81 into main May 2, 2024
9 checks passed
@robertapplin robertapplin deleted the 37175_bad_recfile_fix branch May 2, 2024 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing) ISIS Team: Core Issue and pull requests managed by the Core subteam at ISIS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Corrupted recovery file will stop workbench from opening
3 participants