Produits Entr'ouvert » Passerelle

On peut pas profiter du transaction.on_commit qui est déjà là, et faire juste :

- transaction.on_commit(lambda: job.run(spool=True))
+ transaction.on_commit(lambda: job.run(spool=not try_now))

Thomas Noël a écrit :

On peut pas profiter du transaction.on_commit qui est déjà là, et faire juste :

[...]

Si on est vraiment dans une transaction ça ne va pas faire ce qu'on espère, c'est à dire lancer le job immédiatement histoire d'avoir son résultat dans job.status, on aura systématiquement job.status == 'registered' et rien d'autre.

Ok.

Maintenant pourquoi un "except SkipJob", vu que c'est déjà pris en charge dans le run ?

Aussi, si le try_now a réussi (job.status == 'completed'), je serais pour ne pas continuer (ne pas faire le transaction.on_commit(lambda: job.run(spool=True))) et juste faire un return job.

Autrement dit je pense à :

if try_now:
    job.run(spool=False)
    if job.status == 'completed':
        return job

Thomas Noël a écrit :

Autrement dit je pense à :
[...]

Si tu veux mais il faut surtout avoir conscience que dans le spooler ou dans le job CRON, on peut avoir un timeout aussi long qu'on veut, c'est pour ça qu'on s'en sert, mais lors de l'appel synchrone il faut faire attention voir forcer un timeout court ou plus court; tout l'intérêt c'est d'avoir une réponse quasi immédiate quand ça marche, sinon de se reposer sur une exécution asynchrone sans trop de délais.

Ça c'est pour l'aspect timeout.

Coté transactionnel, quand on utilise try_now il faut éviter d'être dans une transaction ou bien s'assurer que ce qu'on fait dans le job est transactionnel, i.e. peut-être rejoué sans souci si la transaction autour échoue.

Benjamin Dauvergne a écrit :

Thomas Noël a écrit :

Autrement dit je pense à :
[...]

Si tu veux mais il faut surtout avoir conscience que dans le spooler ou dans le job CRON, on peut avoir un timeout aussi long qu'on veut, c'est pour ça qu'on s'en sert, mais lors de l'appel synchrone il faut faire attention voir forcer un timeout court ou plus court; tout l'intérêt c'est d'avoir une réponse quasi immédiate quand ça marche, sinon de se reposer sur une exécution asynchrone sans trop de délais.

Ça c'est pour l'aspect timeout.

Coté transactionnel, quand on utilise try_now il faut éviter d'être dans une transaction ou bien s'assurer que ce qu'on fait dans le job est transactionnel, i.e. peut-être rejoué sans souci si la transaction autour échoue.

Parfaitement d'accord avec tout ça. L'idée du try_now n'est pas de moi :)

Pour tout dire au départ j'étais contre l'idée présentée dans ce ticket. Mais il semble que ça soit utile pour SMART ? Si ce n'est pas le cas, je préfère ne pas avoir d'implémentation de cette affaire qui peut donner de faux espoirs.

Quand le besoin de "tenter d'abord et passer en job sinon", je préfèrerais que l'appel synchrone soit fait directement par l'appelant avant de basculer en job en cas de pépin (timeout rapide ou autre).

Pour info pareil pas fan de l'idée, surtout parce que ça va amener des workflows qui vont être faits en comptant sur les infos d'un résultat immédiat alors que celui-ci ne sera pas garanti.