Remove retrying and submit-retrying states

[kinow]

These changes close #514

Requirements check-list

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Already covered by existing tests.
• No change log entry required (why? e.g. invisible to users).
• No documentation update required.

[kinow]

The checkpoint workflow, used to generate the data for the offline mode uses the retrying state too. So I will need a bit more of time understanding how to rewrite it with an xtrigger (I think that's the replacement).

[codecov-io]

Codecov Report

Merging #526 into master will decrease coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #526      +/-   ##
==========================================
- Coverage   68.02%   67.96%   -0.07%     
==========================================
  Files          44       44              
  Lines         954      952       -2     
  Branches       59       59              
==========================================
- Hits          649      647       -2     
  Misses        288      288              
  Partials       17       17              

Flag	Coverage Δ
unittests	67.96% <ø> (-0.07%)	⬇️

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

Impacted Files	Coverage Δ
src/model/TaskState.model.js	100.00% <ø> (ø)
src/utils/tasks.js	100.00% <ø> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 61c4852...4f2ce48. Read the comment docs.

[hjoliver]

The checkpoint workflow, used to generate the data for the offline mode uses the retrying state too. So I will need a bit more of time understanding how to rewrite it with an xtrigger (I think that's the replacement).

Maybe that's not necessary at this point, until we can represent xtriggers in the UI just use waiting as that is the replacement for retrying in terms of state (it is a waiting task, that is waiting on an xtrigger). So a task that fails and retries several times before succeeding (or failing) will look like this: running -> waiting -> running -> waiting -> succeeded (or failed).

[kinow]

@hjoliver

Maybe that's not necessary at this point, until we can represent xtriggers in the UI just use waiting as that is the replacement for retrying in terms of state (it is a waiting task, that is waiting on an xtrigger). So a task that fails and retries several times before succeeding (or failing) will look like this: running -> waiting -> running -> waiting -> succeeded (or failed).

👍 I replaced retrying and submit-retrying by waiting in our tests already. I thought that the workflow used to generate offline data wouldn't work after the latest changes, and I would have to update it.

But I think you are correct!

But I just tried it, and it executes successfully, producing the JavaScript data for the offline mode 🎉 So nothing else to be done here. Thanks!

[kinow]

@hjoliver assigning you just in case you have time for a quick review today 😬 similar to the other one you reviewed yesterday.

[hjoliver]

👍