Je reçois une erreur 422 :
« Invalid final data counts. One or more of your counts is incorrect. »
Voici ce que j’ai vérifié :
La pagination de GetOrders fonctionne correctement et retourne exactement 50 commandes
FilterDelivered retourne correctement 12 commandes d’entreprise non livrées
SendToOrdersQueue et SendToPriorityQueue ont tous deux retourné des réponses réussies lors de ma dernière exécution complète
Toutes les valeurs de la charge utile finalisée sont du type correct (nombres/booléen, pas des chaînes de caractères)
Je soupçonne que cela pourrait être lié à une soumission antérieure lors du débogage - j’avais initialement complété le « Order Queue Assessment Checkpoint » avant d’ajouter la pagination, quand orders_queued était 10 au lieu de 50. Il est possible que le serveur compare toujours par rapport à ce nombre antérieur au lieu de ma dernière exécution.
Quelqu’un pourrait-il m’aider à vérifier l’état du backend pour mon évaluation, ou me dire comment réinitialiser la progression pour cette section afin que je puisse soumettre à nouveau proprement ?
ID d’évaluation : 7369d82545c8b10f9f5ae4f1b3579603
Salut @muktern8n Bienvenue !
L’erreur nomme tes comptages, pas ta progression, donc c’est le payload plutôt qu’un état backend périmé. batch_size est la seule valeur qui ne correspond pas à l’Étape 2.7, qui utilise 5. Définis BatchPriorityOrders avec une taille de batch de 5, réexécute tout le workflow d’un coup, et finalise avec batch_size: 5.
Vois ceci :
Pour ajouter à ce qu’Anshul a dit, puisqu’il existe un fil avec votre message d’erreur exact (pas celui « Progress incompleted ») où Jamie de l’équipe n8n a confirmé la taille du lot et publié une capture d’écran de l’exécution de référence :
Deux éléments de ce fil que je garderais ouverts lors de votre nouvelle exécution.
La capture d’écran vous permet de vérifier l’exécution avant même d’appuyer sur finalize. Avec 12 commandes entreprise et une taille de lot de 5, BatchPriorityOrders devrait afficher 4 exécutions et SendToPriorityQueue devrait afficher 3 (5, 5, 2). Si le nœud de file d’attente prioritaire affiche toujours 2, la boucle est toujours sur 10 et je ne ferais pas confiance à l’appel finalize tant que ce nombre ne change pas. Votre total_orders 50 et enterprise_count 12 correspondent tous les deux à ce que l’exécution de référence montre, donc batch_size est vraiment le seul nombre qui ne correspond pas.
L’autre chose vers laquelle Jamie a continué à pointer, à la fois dans ce fil et dans celui « Missing required parameter: total_orders » de la semaine dernière, c’est les types. Si le corps de FinalizePipeline est sur « Using Fields Below » et que vous avez tapé 50 et true directement dans les champs de valeur, ils sortent en tant que chaînes de caractères, même s’ils semblent corrects dans l’interface utilisateur.
Pour le point de contrôle final, ce devrait être 5, pas 10. Vos autres valeurs semblent correctes :
{
“total_orders”: 50,
“enterprise_count”: 12,
“batch_size”: 5,
“retry_enabled”: true
}
Je changerais BatchPriorityOrders à une taille de lot de 5, puis j’exécuterais le flux de travail complet du début à la fin et je soumettrais le point de contrôle final.
Donc, je ne pense pas que ce soit lié à la soumission antérieure orders_queued: 10 ou à l’état du backend en cache. Le 422 que vous recevez pointe spécifiquement vers les comptages finaux, et batch_size: 10 est la valeur qui ne correspond pas à l’exigence du cours.
Merci Subham, batch_size: 5 était effectivement la solution, et SendToPriorityQueue s’exécute maintenant avec succès (tous les lots au vert, 12 éléments confirmés).
Cependant, FinalizePipeline affiche maintenant une erreur différente : « Progress incompleted. You have not completed all steps in this assessment. » C’est déroutant car dans cette même exécution complète : - SendToOrdersQueue a confirmé orders_queued: 50 - SendToPriorityQueue s’est exécuté au vert pour tous les lots (12 éléments au total) - FinalizePipeline payload: { “total_orders”: 50, “enterprise_count”: 12, “batch_size”: 5, “retry_enabled”: true } Tout a réussi dans cette exécution, et pourtant l’étape de finalisation dit encore que la progression est incomplète.
Cela ressemble à ce qu’un autre utilisateur a signalé ci-dessus avec un problème similaire. Quelqu’un pourrait-il vérifier l’état du checkpoint du backend pour mon Assessment ID ?
@muktern8n Une vérification backend n’est pas nécessaire, le défaut est dans votre flux. Vous avez répertorié les commandes en attente comme 50, comme preuve que l’étape 1 a réussi, cependant, dans un autre fil, il a été dit que la partie étape 1 veut seulement 10, donc vous devez désactiver la pagination.
Merci pour votre réponse, mais je pense que ce n’est peut-être pas correct — le document du cours indique explicitement aux étapes 2.1-2.2 que la pagination doit retourner 50 commandes, et le code de confirmation pour ce point de contrôle contient littéralement « PAGED-ORDERS-QUEUE » dans son nom, que j’ai reçu avec succès. Le reste de l’exercice (20 Enterprise / 30 autres, 12 non livrées) n’a de sens qu’avec 50 commandes, pas 10.
Pouviez-vous partager le fil de discussion spécifique où « seulement 10 » a été mentionné ? Je veux m’assurer que je ne manque pas un autre contexte, mais selon ma copie du matériel de cours, la pagination à 50 semble être une étape obligatoire, pas facultative.
