protection de l'API pour des commandes concurrentes sur la même branche

[gmaillet]

Propositions de modification liées à #418
Cette PR est basé sur #417 qui devrait être mergée avant cette PR.

Testée uniquement en local et sous windows, à valider sous Linux avec une attention particulière sur les performances et l'impact sur l'utilisation de la BD Postgres.

[coveralls]

Pull Request Test Coverage Report for Build 9744546129

Details

• 95 of 116 (81.9%) changed or added relevant lines in 7 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.2%) to 95.772%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
middlewares/branch.js	32	38	84.21%
gdal_processing.js	35	50	70.0%

Totals
Change from base Build 9659724665:	-0.2%
Covered Lines:	6017
Relevant Lines:	6234

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 9759201786

Details

• 60 of 66 (90.91%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.07%) to 95.772%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
middlewares/branch.js	32	38	84.21%

Totals
Change from base Build 9757489901:	-0.07%
Covered Lines:	6017
Relevant Lines:	6234

---

💛 - Coveralls

[amrosu]

J'ai testé en local sous Linux et je n'ai pas observé de ralentissement sur mes petits caches.
Pour tester les performances, il faudrait tester sur des caches de prod, avec plusieurs utilisateurs concurrents...

[gmaillet]

Testé sur l'infra de production: j'ai l'impression que le code fonctionne, mais visiblement le verrouillage n'est pas suffisant dans le cas où on utilise deux serveurs. Je pense qu'il y a un mécanisme de cache sur les montages NFS du store. Du coup, le traitement est vu comme terminé sur un serveur, mais l'état n'est pas encore cohérent sur l'autre serveur.

C'est tout de même beaucoup moins fréquent.

Il reste encore la possibilité d'intercepter l'erreur du rename (voir exemple ci-dessous) puisque maintenant on sait qu'en attendant un peu avant une nouvelle tentative ça devrait fonctionner.

(node:172225) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, rename '/mnt/store-SIA/PACKO/cache_ortho_tipi/cache_packo/graph/21/00/00/22/YA/232_G0.tif' -> '/mnt/store-SIA/PACKO/cache_ortho_tipi/cache_packo/graph/21/00/00/22/YA/232_G0_1.tif'
at Object.renameSync (fs.js:798:3)
at rename (/var/packo/middlewares/patch.js:49:6)
at /var/packo/middlewares/patch.js:490:5
at Array.forEach ()
at undo (/var/packo/middlewares/patch.js:457:9)
at runMicrotasks ()
at processTicksAndRejections (internal/process/task_queues.js:95:5)

[coveralls]

Pull Request Test Coverage Report for Build 10097129156

Details

• 196 of 241 (81.33%) changed or added relevant lines in 7 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.7%) to 95.172%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
middlewares/branch.js	32	38	84.21%
middlewares/patch.js	136	175	77.71%

Files with Coverage Reduction	New Missed Lines	%
middlewares/patch.js	1	90.31%

Totals
Change from base Build 9757489901:	-0.7%
Covered Lines:	6044
Relevant Lines:	6300

---

💛 - Coveralls

[gmaillet]

J'ai poussé une nouvelle version qui vérifie l'accès à tous les fichiers avant de commencer les renommages (pour les undo/redo). En cas d'erreur sur l'un des fichiers: on ne fait rien et on informe l'utilisateur. Cela évite de faire les modifs à moitié et de compromettre l'intégrité du cache (et de bloquer l'API avec un exception non gérée).
Je ne suis pas certain que ça élimine tous les risques dans le cas de l'utilisation de plusieurs serveurs avec du cache NFS, mais ça me semble plus sain.