Hmm, je pensais avoir trouvé quelque chose… mon utilisateur de test « empoisonné », george21, était au niveau TL0. Alors je l’ai passé à TL1 et cela a fonctionné. Ok ! Peut-être que c’est ça ! Alors j’ai remis george21 à TL0… et maintenant il n’est plus « empoisonné » — il peut effectuer l’appel API même en tant que TL0.
Maintenant, je relance mon script d’importation, et aha. Maintenant, george21 génère une erreur 500 dans le script d’importation. Et quand j’essaie dans Insomnia, cela échoue. Alors je remets george21 à TL1 et… oui, il peut exécuter l’appel HTTP.
Voici donc ce que je parviens apparemment à reproduire :
- Si une série d’appels API est effectuée (?), cela provoque d’une manière ou d’une autre l’échec d’un appel API ultérieur avec un utilisateur TL0.
- Changer l’utilisateur TL0 en TL1 permet à l’appel API de passer.
- Étrangement, changer ce même utilisateur de nouveau en TL0 permet toujours à l’appel API de passer.
- Relancer le script fonctionne bien jusqu’à ce qu’il échoue à nouveau avec un autre utilisateur TL0.
Notez que :
- À ma connaissance, tous les minimums, etc., pour TL0 ont été relevés (c’est-à-dire que j’ai essayé de supprimer chaque blocage empêchant un utilisateur TL0 de poster), et
- Même s’il s’agit d’un problème lié à une sorte de limite de taux interne pour les utilisateurs TL0, l’API ne devrait pas renvoyer une erreur 500 et inscrire une erreur SQL dans le journal des erreurs. Nous pouvons donc affirmer à ce stade qu’il y a définitivement un bug quelque part.
Oui, euh, je sais, et j’ai déjà expliqué quatre fois pourquoi je n’écris pas mon propre script d’importation (basé sur les exemples donnés). 
D’où mon changement d’approche.
En attendant, je continue de contribuer ici pour essayer d’aider à trouver et corriger ce bug. Aujourd’hui, cela impacte mon script d’importation. Demain, cela pourrait être un script important que vous avez sur votre site et qui a besoin de l’API…