Après POST /taches/{id}/declencher, la tâche ne repart plus selon son planning

Votre rapport était exact, et il décrivait un défaut plus large que le vôtre. Merci : sans la précision de vos horodatages, on ne l'aurait pas trouvé aujourd'hui.

Ce qui se passait

La prise d'une occurrence avance l'échéance par comparaison-échange : « avance-la, mais seulement si elle vaut encore ce que je viens de lire ». C'est ce qui empêche deux workers de lancer deux fois la même exécution — une faute irréversible quand la tâche débite un client.

Or la colonne garde la microseconde, et le worker, écrit en JavaScript, ne sait compter qu'en millisecondes. Il lisait 07:44:12.345678, renvoyait 07:44:12.345, et la condition ne correspondait plus à aucune ligne. À chaque passage, indéfiniment.

Mesuré sur notre base, cinq essais sur cinq :

en base 18:15:03.412621 | lu par le worker 18:15:03.412 | prise : 0 ligne

Pourquoi vos quinze autres tâches tournaient

Une échéance de cron tombe sur la seconde ronde — 07:40:00.000000 fait l'aller-retour intacte. Seuls deux chemins produisent un instant à la microseconde, et tous deux écrivent now() directement en base :

• le déclenchement manuel, now() - 1 seconde — le vôtre ;
• le réveil d'une tâche enchaînée.

Le second n'avait jamais été rencontré : aucune tâche enchaînée n'existe encore chez nos clients, et nos 36 938 exécutions enregistrées sont toutes d'origine « planning ». Autrement dit l'enchaînement ne fonctionnait pas du tout, et le premier à s'en servir aurait trouvé ses tâches gelées sans explication. Votre rapport nous l'a évité.

Ce que nous confirmons de votre trace

Nous avons relu l'historique de la tâche. Exécutions à 07:01, 07:10, 07:20, 07:31 — puis rien jusqu'à 08:00, qui correspond à votre contournement. Et le worker, lui, a bien exécuté d'autres tâches à 07:40, 07:45 et 07:50 : il était vivant. Votre lecture était juste de bout en bout.

Un point que nous retenons comme aussi grave que la panne : l'historique ne portait rien. Ni « périmée », ni « chevauche », ni échec. Le continue arrivait avant toute écriture, donc une tâche critique s'arrêtait en se présentant comme active. C'est la pire panne qu'un ordonnanceur puisse avoir, parce qu'elle ne se signale pas.

Le correctif

Il est dans la colonne, pas dans les deux requêtes fautives. Arrondir à l'écriture aurait fait deux corrections au lieu d'une, et laissé le piège en place pour le troisième appelant — qui l'ignorerait comme les deux premiers l'ignoraient. Une colonne dont la précision dépasse ce que l'application sait représenter est un piège pour tout écrivain.

L'échéance est donc ramenée à la milliseconde : la base arrondit elle-même, quel que soit le chemin, et l'aller-retour devient exact par construction. Deux tests le gardent, l'un pour le déclenchement manuel et l'autre pour l'enchaînement ; les deux échouaient avant le correctif.

Ce que vous avez à faire

Rien. Votre contournement — pause puis reprise — n'est plus nécessaire, et les tâches déjà gelées repartent d'elles-mêmes au premier passage suivant le déploiement. Vous pouvez à nouveau utiliser POST /taches/{id}/declencher sans risque.

Un second point, que nous devons à votre remarque sur le silence : declencher répondait « declenche: true » sans vérifier que la mise à jour avait touché une ligne. Les gardes sur le mode et la pause sont bien faites avant l'écriture, mais rien ne garantissait que l'état n'avait pas changé entre les deux : une tâche mise en pause dans l'intervalle rendait un succès pour un déclenchement qui n'avait pas eu lieu. La route répond maintenant d'après ce que l'écriture a réellement fait, et rend un 409 si la tâche n'est plus exécutable. Un faux succès est pire qu'une erreur : l'erreur s'apprend tout de suite.

Merci encore. C'est le genre de rapport — ce que j'ai fait, ce que j'attendais, ce que j'obtiens, avec les heures — qui permet de trouver une cause en une après-midi au lieu d'une semaine.