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 problem with prematurely erased sandbox folder retrieved_temporary_folder #1168

Merged

Conversation

sphuber
Copy link
Contributor

@sphuber sphuber commented Feb 20, 2018

Fixes #1166

The new feature of the retrieve_temporary_list employed an unstored FolderData
node, added to the retrieved dictionary to be passed to the parse_from_retrieved
method of the Parser. The problem is that the temporary folder can be erased
when the object is garbage collected, since that is called in the del method
of the Node class, if it has an unstored sandbox folder. This didn't use to get
called with the old daemon, but with the new daemon and process system, somewhere
in the pipeline this gets triggered causing the sandbox folder to be deleted at
the time it gets to the parse_with_retrieved call.

The solution is to replace the FolderData simply with an absolute folder path
which can be used by the caller to populate with a temporary folder, that is
created within a context manager and will be guaranteed by the caller to be
kept alive until the parse call is completed, upon which it will be destroyed.

…y_folder

The new feature of the retrieve_temporary_list employed an unstored FolderData
node, added to the retrieved dictionary to be passed to the parse_from_retrieved
method of the Parser. The problem is that the temporary folder can be erased
when the object is garbage collected, since that is called in the __del__ method
of the Node class, if it has an unstored sandbox folder. This didn't use to get
called with the old daemon, but with the new daemon and process system, somewhere
in the pipeline this gets triggered causing the sandbox folder to be deleted at
the time it gets to the parse_with_retrieved call.

The solution is to replace the FolderData simply with an absolute folder path
which can be used by the caller to populate with a temporary folder, that is
created within a context manager and will be guaranteed by the caller to be
kept alive until the parse call is completed, upon which it will be destroyed.
@sphuber sphuber force-pushed the fix_1166_retrieved_temporary_folder branch from 3212205 to c9b3095 Compare February 20, 2018 22:56
@giovannipizzi giovannipizzi merged commit 03b1d18 into aiidateam:workflows Feb 21, 2018
@sphuber sphuber deleted the fix_1166_retrieved_temporary_folder branch February 21, 2018 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/critical-blocking must be resolved before next release topic/daemon type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants