Fix aiida.cmdline.utils.decorators.load_backend_if_not_loaded
#4878
Conversation
|
The question now is how we test that nothing else is broken 🤔 |
yeh thats I was gonna say lol; are you 100%, totally and utterly sure this is fully fixed 😬 |
No. It is clear that our unit tests would not catch this problem. I am pretty sure about the analysis as to the cause and that should be fixed, but there is no telling if there is anything else broken that is being hidden.
Can refactor this into two utility methods |
|
I have to say, I don't really get the purpose of #4865 in the first place; since |
|
oh and there is also, already the |
Codecov Report
@@ Coverage Diff @@
## develop #4878 +/- ##
===========================================
+ Coverage 79.67% 79.68% +0.01%
===========================================
Files 523 523
Lines 37168 37169 +1
===========================================
+ Hits 29610 29614 +4
+ Misses 7558 7555 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
You are right, the fix did prevent the spinner from unnecessarily appearing but |
sphuber
force-pushed
the
fix/4877/load-backend-if-not-loaded
branch
from
76e4610
to
e799862
Compare
| manager = get_manager() | ||
|
|
||
| if not manager.backend_loaded: | ||
| with spinner(): |
There was a problem hiding this comment.
hmm, do we really have to load two spinners now.
Maybe just do if get_profile() is None or not manager.backend_loaded
There was a problem hiding this comment.
and then always call load_profile relying on its internal shortcut to not load again if already loaded?
The function incorrectly used the `PROFILE` global variable to determine whether the database backend environment had been loaded. This variable is set as soon as a profile is loaded, however, this does not automatically mean that the database environment is also loaded. These two actions are separate on purpose such that a profile can be loaded without having to load the backend, since that is an expensive operation and is not always necessary. This bug meant that sometimes the backend would actually not be loaded even though the `with_dbenv` decorator was correctly used. This affects, among other things, all CLI commands that rely on the backend being loaded but having no code in its execution path that will automatically load the backend, such as `verdi archive import`. Any commands that deal with the ORM still work, since loading any ORM entity will automatically load the backend of the current profile if not already done. Since the import functionality circumvents the ORM, it didn't have this failsafe operation. Finally, the bug was not noticed by the unittests because they run in an environment where the database backend is loaded anyway for the test profile effectively hiding the bug of the `load_backend_if_not_loaded` method.
sphuber
force-pushed
the
fix/4877/load-backend-if-not-loaded
branch
from
e799862
to
5c15aca
Compare
The function incorrectly used the `PROFILE` global variable to determine whether the database backend environment had been loaded. This variable is set as soon as a profile is loaded, however, this does not automatically mean that the database environment is also loaded. These two actions are separate on purpose such that a profile can be loaded without having to load the backend, since that is an expensive operation and is not always necessary. This bug meant that sometimes the backend would actually not be loaded even though the `with_dbenv` decorator was correctly used. This affects, among other things, all CLI commands that rely on the backend being loaded but having no code in its execution path that will automatically load the backend, such as `verdi archive import`. Any commands that deal with the ORM still work, since loading any ORM entity will automatically load the backend of the current profile if not already done. Since the import functionality circumvents the ORM, it didn't have this failsafe operation. Finally, the bug was not noticed by the unittests because they run in an environment where the database backend is loaded anyway for the test profile effectively hiding the bug of the `load_backend_if_not_loaded` method. Cherry-pick: e335e30
Fixes #4877
The function incorrectly used the
PROFILEglobal variable to determinewhether the database backend environment had been loaded. This variable
is set as soon as a profile is loaded, however, this does not
automatically mean that the database environment is also loaded. These
two actions are separate on purpose such that a profile can be loaded
without having to load the backend, since that is an expensive operation
and is not always necessary.
This bug meant that sometimes the backend would actually not be loaded
even though the
with_dbenvdecorator was correctly used. This affects,among other things, all CLI commands that rely on the backend being
loaded but having no code in its execution path that will automatically
load the backend, such as
verdi archive import. Any commands that dealwith the ORM still work, since loading any ORM entity will automatically
load the backend of the current profile if not already done. Since the
import functionality circumvents the ORM, it didn't have this failsafe
operation.
Finally, the bug was not noticed by the unittests because they run in an
environment where the database backend is loaded anyway for the test
profile effectively hiding the bug of the
load_backend_if_not_loadedmethod.