history updated just if acquisition succeeded

[lballerio]

When something crashes in the execution of experiments during the _fit step, the program still saves the data.npz file so in theory it is still possible to fix the fitting function and test it using the CLI command qq fit.
However it does not work out of the box since in this scenario history.json does not contain the failed task, hence it ignore those data.
In thi PR indeed I try to update this json file with the sufficient and necessary condition that acquisition step succedeed. This solves the scenario described above.
Of course this is simply postponing an eventual crash in the code in the following lines, where indeed the Executor sees history.json has been updated with the task and look for results.json even though it does not exist.

Finally it modifies a small bug that I found in task.py:run method, that from what I saw probably it has never been triggered.

[codecov]

Codecov Report

❌ Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.78%. Comparing base (3cd5a96) to head (973d156).
⚠️ Report is 360 commits behind head on main.

Files with missing lines	Patch %	Lines
src/qibocal/auto/task.py	57.14%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1401      +/-   ##
==========================================
- Coverage   96.79%   96.78%   -0.02%     
==========================================
  Files         133      133              
  Lines       10463    10468       +5     
==========================================
+ Hits        10128    10131       +3     
- Misses        335      337       +2     

Flag	Coverage Δ
unittests	96.78% <57.14%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/qibocal/auto/task.py	95.26% <57.14%> (-1.69%)	⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[alecandido]

Never do this, keep it None

[alecandido]

Moreover, the if mode is None you introduced yourself below is already doing the replacement

[alecandido]

Never explicitly mention lines of code: these comments are going to age fast, and become obsolete and confusing. Mention the location "conceptually", naming their role, rather than the physical position.

[alecandido]

mode is a Flag enum, specifically of type ExecutionMode.

Instead of making it an empty list, which is succeeding in the current usage, but just broadening the type hint, create instead an instance of ExecutionMode.

If you want to keep it empty as a default (which is a choice), it is possible to create the equivalent enum variant, e.g. with ExecutionMode.ACQUISITION & ExecutionMode.FIT (empty intersection).
It is a bit convoluted, and because of this in py3.11 on you can do ExecutionMode(0). But we still support also py3.10

Btw: the reason not to put an empty list as default argument is because it is a mutable object, and it would be shared by all calls (search this online, you will find plenty of references and examples). However, ExecutionMode instances should not be mutable, because they are essentially integers. So, that one could be set even as default argument, and you could avoid both the Optional and the default to None. Though that's also a choice: sometimes having a special value for the unset state is useful. But, in my experience, better to avoid whenever not explicitly needed

[lballerio]

then what about using a tuple?

[alecandido]

Do you mean a tuple of Booleans? That's exactly what a flag is, essentially a bitstring :)

[lballerio]

I was more thinking about changing the default value to an empty tuple, which then is immutable and will be fine with the immutability condition, on which by the way I completely agree.
The thing is that there is a clear inconsistency in the default value for variable mode, since if you don't assign any value the code will crash because of the command:

if ExecutionMode.Something in None:

Then, I don't know if this condition might be forced or is suppressed in higher levels in the code.

Also, the main purpose of this small PR is to put acquisition as necessary and sufficient condition for updating the history in the output folder.