[Résolu] Lancer des actions sécurisées par lot en asynchrone ? OK en HTTP, KO en PHP

Bonjour,

Je viens de finaliser une action qui permet de retraiter une image.

function action_traiter_un_document_dist($arg = null) {

// mes traitements !

}

Ailleurs, je génère à la volée des urls d’actions pour cette action puis je tente un queue_lancer_url_http_async() pour lancer en asynchrone les appels à ces actions (car elles prennent environ 30’ chacune) :

include_spip('inc/actions');
include_spip ('inc/queue');
include_spip('action/traiter_un_document');

	foreach ($documents_lies as $document_lie) {
		
		# Appeller l'action unitaire de traitement
		$id_document = $document_lie["id_document"];
		
		$url = generer_action_auteur("traiter_un_document", "document-$id_document");
		$res = queue_lancer_url_http_async($url);
		
	}

Les urls d’actions produites ressemblent à ça :
https://www.mondomaine.tld/spip.php?action=traiter_un_document&arg=document-5971&hash=1399273e7d271ddec6f01c18b1ff02ecb8698093d03899fc892bc5a8e9d476b5

Si je les lance à la main dans mon navigateur : l’action est bien réalisée :slight_smile:
Mais ce n’est pas le cas en passant par ma boucle for, je constate simplement que queue_lancer_url_http_async() me renvoie true, mais aucune action n’a été réalisée :frowning:

Avez-vous des pistes, des suggestions ?

Merci à vous,

Pierre-Jean

PS. : je me suis basé sur la doc, ici : Fonction queue_lancer_url_http_async - Programmer avec SPIP 4

Précise ton diagnostic : tu indiques que l’action n’est pas réalisée, mais il faudrait savoir si elle est appelée et qu’elle échoue, et où elle échoue alors… car au début d’une action il y a normalement des tests pour récupérer son argument et authentifier l’appel… Ou si elle n’est en fait pas du tout appelée pour de vrai (au cas où queue_lancer renvoie true quand même car il croirait que ça se passe bien) ou pas la bonne version… (plein de trucs possibles)

Hello @JLuc ,

Merci pour ton retour, je précise mon workflow car j’ai deux actions en tout : une « meta action » qui liste toutes les « actions unitaires » à faire.

  1. Depuis /ecrire j’appuie sur un premier bouton d’action qui sert uniquement à générer puis appeler en asynchrone des actions unitaires de traitement pour chaque document lié à un objet.

  2. Cette première « meta action » est bien appelée et grâce au plugin Notifbox de @placido j’arrive à afficher en live les urls de chaque action unitaire de traitement (pour chaque document, une url d’action est générée puis appelée).

  3. L’url de chaque action unitaire est correcte, le hash est bien là…

  4. Lorsque dans la boucle for de ma première « meta action » je tente d’appeler une action unitaire en faisant $res = queue_lancer_url_http_async($url); , j’obtiens true mais aucune modification en base n’est réalisée (c’est ce que j’attends).

  5. J’utilise aussi l’action unitaire de traitement directement depuis la vue d’un document donné via un bouton d’action (sans passer par la « meta action ») : l’actions se réalise.

  6. En récupérant les urls de chaque « action unitaire » produites par la « meta action » et en les collant dans la barre d’url de mon navigateur, l’action se réalise.

  7. J’en viens à me dire que la seule chose qui coince est liée à l’appel de l’action unitaire depuis la « meta action » => y a t’il des choses particulières à faire/savoir pour appeler une action depuis une autre action ?

Où encore, serait-il possible que la première action (meta action) lance tous les appels et se clôture => ainsi toutes les actions unitaire lancées en asynchrone pourraient elles-mêmes être clôturées par l’arrêt de la meta action ?

J’ai tenté un sleep() de 70 secondes dans ma « meta action » pour laisser le temps aux actions unitaires de se réaliser, mais sans succès…

À part des inclure ou des autorisations manquantes, je ne comprends pas cette différence de fonctionnement entre un appel direct en HTTP de l’action ou via la fonction queue_lancer_url_http_async() de SPIP.

Re,

Problème résolu ! Quel soulagement !

La doc indique un exemple d’appel de la fonction queue_lancer_url_http_async($url); en s’appuyant sur la fonction $url = generer_action_auteur(‹ peupler_territoires ›, $arguments); avec seulement deux paramètres passés à la fonction. Et je n’ai pas cherché plus loin.

En fouillant via l’excellent nouveau et rapide explorateur de code les usages de la fonction generer_action_auteur(), couplé à la fonction asynchrone j’ai remarqué qu’elle admettait 6 paramètres contre 2 dans l’exemple de la doc.

En passant de :
$url = generer_action_auteur("corriger_description_document", "document-$id_document");
à
$url = generer_action_auteur("corriger_description_document", "document-$id_document", '', true, 0, true);

J’obtiens le résultat escompté, à savoir générer des actions sécurisées en lot et les exécuter de manière asynchrone. Magnifique !

Merci à @JLuc et j’espère que cela puisse en aider d’autres si la doc n’est pas mise-à-jour entre-temps.

Bonne journée à tous !

3 « J'aime »

Super. Alors j’ai ajouté une petite remarque dans la doc : « Rq : selon les contextes et besoins, il peut être nécessaire d’utiliser les autres arguments de la fonction generer_action_auteur »

A propos : voudrais tu peut être rejoindre la team documentation ?

2 « J'aime »

Hum, j’aimerais effectivement pouvoir participer plus à l’effort collectif,.

Je n’avais pas pensé à la partie documentation, mais effectivement, ça fait sens aux vues de mes interactions sur discuter et de ma pratique de tous les jours.

C’est documenté où ?

Sur le lien « doc » cité plus haut par Pierre-Jean : Fonction queue_lancer_url_http_async - Programmer avec SPIP 4

Ah oui, je n’avais pas vu.
Merci pour la doc, à toi et à @Pierre_Jean

Alors bienvenue à l’effort collectif qui te convient le mieux @Pierre_Jean (et c’est l’occasion de paraphraser @JamesRezo ) : normalement, tu peux demander à rejoindre l’é ou les-é quipe de ton choix via Discuter de SPIP