Si une publication programmée n'est toujours pas apparue, ne la renvoyez pas encore. Convertissez l'heure planifiée en Asia/Bangkok, collectez le content ID et le job ID, vérifiez le provider ID ou l'URL du provider original et confirmez si le texte, le média, la publication racine et les réponses sont complets. Si la réponse du système est manquante, enregistrez le résultat comme inconnu avant de décider de réessayer.

Il ne s’agit pas d’une simple question de réussite ou d’échec. L’outil de planification et la publication visible sur le réseau peuvent être mis à jour à des moments différents. Le job peut encore être en file d’attente, la publication peut n'être que partiellement publiée ou la publication peut avoir réussi même si la réponse n'a jamais atteint l'outil. Une ligne de preuve par destination permet de distinguer ces cas.

Ce guide s'adresse aux opérateurs de médias sociaux en Thaïlande qui doivent prendre une décision de nouvelle tentative en toute sécurité. Il utilise un horodatage thaïlandais explicite, des identifiants traçables et le résultat visible dans le provider original.

Réponse courte : Que dois-je vérifier lorsqu'une publication programmée n'apparaît pas ?

Vérifiez les 5 groupes principaux dans l'ordre : compte et chaîne, heure définie sur Asia/Bangkok, content ID ou de tâche, dernier statut et provider original avec résultats publics. Vérifiez ensuite l'intégralité du message, du média, du lien racine et répondez si les preuves ne suffisent pas. Arrêtez de renvoyer et sélectionnez « En attente » ou « Inconnu ».

Le renvoi n'est pas un test de diagnostic. Il change d'état réel et peut créer un deuxième objet fournisseur, avant de réessayer il faut d'abord confirmer que le premier objet n'existe pas. Ou est-il présent mais il manque une pièce ?

Aligner l’heure sur le fuseau Asia/Bangkok

La Thaïlande utilise le fuseau horaire Asia/Bangkok, qui est UTC+07:00. Il ne suffit pas de stocker le mot « 16h30 » car il n'indique pas la date, le fuseau horaire ou la valeur que le système enregistre au format UTC.

Pour les posts prévus le 15 août 2026 à 16h30 à Bangkok, conservez au minimum ces deux formats :

scheduled_local: 2026-08-15 16:30 Asia/Bangkok
scheduled_iso:   2026-08-15T16:30:00+07:00
scheduled_utc:   2026-08-15T09:30:00Z

Lorsqu'un écran affiche l'heure thaïlandaise et un autre affiche UTC, comparez l'heure normalisée, pas l'heure exacte. 09:30Z et 16:30+07:00 représentent le même instant.

Au moins quatre valeurs temporelles doivent être séparées :

Temps Utilisé pour répondre à quelle question Je ne peux toujours rien prouver
scheduled_at Quand les travaux doivent-ils commencer ? Le fournisseur a-t-il reçu le courrier ?
job_created_at Quand le métier d’éditeur a-t-il été créé ? Le travail est-il terminé ?
provider_published_at fournisseur indique quand il a été publié Le contenu et les liens sont-ils affichés correctement ?
observed_at Quand vérifions-nous les pages publiques ? Que se passe-t-il entre deux contrôles

N'écrasez pas l'heure définie par l'heure de publication réelle. Conservez les deux pour séparer « lancé lentement » de « publier à temps mais le statut revient tard ».

content ID, job ID et ID de fournisseur distincts

Les trois types d'identifiants ne sont pas le même mot. et ne doivent pas être combinés dans un seul champ de note.

Content ID correspond à la portée du contenu et à sa destination

Content ID identifie les messages, médias, comptes et heures approuvés. Lorsqu'une erreur se produit, ouvrez le contenu original avant d'en créer un nouveau. pour voir quelle destination a été envoyée et quelles valeurs ont été enregistrées.

job ID est un effort de publication qui peut suivre son statut

le job ID est utilisé pour suivre les tâches de scheduled ou publishing jusqu’à l’état de destination, tel que published ou failed. Si vous disposez déjà d'un job ID, vérifiez la tâche d'origine, et non créez une nouvelle tâche, pour voir ce qui se passe.

le provider ID ou le lien permanent est un objet du côté social

Les identifiants de fournisseur renvoient à des objets réseau, tandis que les permaliens permettent un accès direct à la publication d'origine. Avoir cette pièce d'identité est une preuve importante que le prestataire a peut-être accepté le poste. Mais vous devez toujours vérifier les comptes, les messages, les médias, les liens et la structure que les lecteurs voient.

Formats d'enregistrement pratiques :

channel_account:
scheduled_local:       Asia/Bangkok
scheduled_utc:
content_id:
job_id:
last_status:
provider_id_permalink:
text_outcome:
media_outcome:
link_outcome:
root_reply_outcome:
acknowledgement:       confirmed | ambiguous
observed_at:
next_check_at:

N'incluez pas de mots de passe, de jetons d'accès, d'invites privées, d'informations client ou d'URL de téléchargement signées dans cet enregistrement. Utilisez uniquement des métadonnées fonctionnelles et vérifiables du fournisseur.

Un statut published ne prouve pas que le message est terminé

L’état de destination répond à la manière dont le flux de travail rapporte. Mais l'exhaustivité doit être vérifiée à partir du message d'origine. Séparez chaque partie pour que la réussite de l’une ne cache pas les échecs de l’autre.

Une partie de l'inspection Passé quand Les résultats des échantillons sont incomplets
Texte Le contenu correspond à la version approuvée Coupe ou utilise du texte dans la mauvaise langue
Médias Les images ou vidéos correctes peuvent être affichées racine a du texte mais le média est manquant
Lien a une ancre sur laquelle on peut cliquer et va à la bonne destination Je peux voir l'URL en lettres mais je ne peux pas cliquer sur
racine est dans le bon compte et dans le bon fil de discussion root est dans le mauvais compte
réponses Numéro, séquence et contenu complet root publie uniquement les réponses avec des liens manquants

Si root a publié mais que la réponse a disparu, le résultat correct est Partiellement publié Tous n'ont pas réussi. Et tout n’a pas échoué. La soumission à nouveau de l'ensemble complet peut entraîner une racine en double.

Si le message et le média sont complets, mais que l'URL n'est qu'un texte sur lequel on ne peut pas cliquer, alors le résultat du lien doit être enregistré comme incomplet, même si le statut est published.

Lorsque l’accusé de réception n’est pas clair, que faut-il faire avant de réessayer ?

Un délai d'attente, un écran gelé ou une réponse vide ne prouve pas que le fournisseur a rejeté la tâche. La demande a peut-être atteint le fournisseur, mais l'accusé de réception n'est jamais parvenu au client.

Enregistrez acknowledgement: ambiguous. et faites-le dans cet ordre :

  1. Lisez le content ID d'origine pour vérifier le compte et le contenu.
  2. Lisez l'ID de travail d'origine jusqu'à l'état de destination ou planifiez la prochaine inspection.
  3. Vérifiez si un identifiant de fournisseur ou un lien permanent a déjà été créé.
  4. Ouvrir un compte public pendant la période correcte Asia/Bangkok
  5. Comparez les messages, les médias, les liens racine et les réponses un par un.
  6. Réessayez uniquement les parties dont il est prouvé qu'elles ne se sont pas encore produites. et n'affecte pas les parties déjà publiées

Le mot ambigu est utile car il empêche le système de convertir automatiquement « pas encore connu » en failed.

Table de décision avant de réessayer un message

Preuve vue Verdict Œuvre suivante
Le travail a été terminé avec succès, le compte est correct et toutes les pièces sont complètes avec le fournisseur d'origine Confirmé Conservez les preuves, ne les soumettez pas à nouveau
le client signale des erreurs ou aucun accusé de réception, mais un objet fournisseur peut exister Vérifiez avant de réessayer Lire l'identifiant original et vérifier l'original
Statut toujours scheduled/publishing et le temps d'inspection est toujours dans le cadre attendez Définissez next_check_at en utilisant Asie/Bangkok
la racine est là mais certains médias/liens/réponses sont manquants Publier quelques parties Séparer la pièce finie et la pièce inachevée
Aucune pièce d'identité ou impossible de vérifier les résultats publics Mise en attente – pas encore connu Arrêtez la récupération automatique et collectez plus de preuves

Ce tableau sélectionne la prochaine inspection. La cause n'a pas été diagnostiquée. Si vous avez besoin de trouver la cause, ajoutez plus de journaux et de preuves du fournisseur sans créer de nouvelle publication.

Exemple en heure de Thaïlande : la racine est arrivée mais la réponse n'est pas encore arrivée

Supposons que le fil de discussion soit fixé à 20h00. Asia/Bangkok ou 13:00Z. Le contenu et l'ID de travail sont créés. À 20h02, root apparaît dans le bon compte, mais la réponse avec le lien n'est pas encore apparue et le client affiche un timeout.

Cette preuve indique que le fournisseur a reçu au moins root, donc ne renvoyez pas l'intégralité du fil de discussion. Notez le provider ID racine, l'heure observed_at et root_reply_outcome: partial, puis vérifiez la tâche d'origine et recherchez les réponses qui pourraient être en retard.

Si la réponse apparaît plus tard, ajoutez l'ID de réponse et vérifiez le lien réel. S'il n'apparaît pas après l'expiration de la fenêtre et la fin du travail, la récupération doit être limitée à la section de réponse, en vérifiant toujours en premier l'idempotence et le provider original.

Utilisez le vérificateur gratuit comme feuille de calcul dans votre navigateur

Vérificateur de preuve de publication sociale Obtenez des informations sur le canal/compte, l'heure de définition du contenu ou de le job ID, le dernier statut et l'URL du fournisseur ainsi que les résultats publics. Regroupez ensuite les décisions en groupes. déterministe Cet outil ne nécessite pas de connexion. Compte non connecté et n'envoie pas les informations saisies depuis le navigateur

Ouvrir gratuitement le vérificateur de preuves de publication sociale

Pour travailler en Thaïlande, saisissez Asia/Bangkok ou le décalage ISO +07:00. Toujours prêt avec la date. Copiez ensuite les résultats dans votre journal des incidents pour un stockage à long terme.

Questions fréquemment posées

En quoi l’Asie/Bangkok est-elle différente de l’UTC ?

Asia/Bangkok C'est un fuseau horaire qui utilise les règles de la Thaïlande et a un décalage de +07:00. UTC est la norme de référence. L’heure 16h30 à Bangkok est égale à 09h30Z le même jour. L'heure locale et l'heure UTC doivent être conservées pour comparer plusieurs systèmes.

Si le statut est publié mais que le lien n'est pas disponible, est-il considéré comme réussi ?

Succès uniquement en termes de statut Mais les résultats publics ne sont pas encore complets si le lien est approuvé. Enregistrez link_outcome séparément du statut du terminal et ne présumez pas que la publication est terminée à partir du seul badge vert.

Si le statut est failed, dois-je réessayer immédiatement ?

Non, jusqu'à ce que le content ID, le job ID, l'ID de fournisseur et le compte public soient vérifiés pour détecter l'absence d'objets en conflit. Les réponses manquantes peuvent coexister avec des objets fournisseur créés avec succès.

Que dois-je faire si je n'ai pas d'URL de fournisseur ?

Utilisez le contenu d'origine ou le job ID pour vérifier d'abord le statut et l'identité du fournisseur. Si l'ID et l'URL ne sont pas disponibles et que les résultats publics ne peuvent pas être vérifiés, sélectionnez « En attente – Inconnu » au lieu de créer une nouvelle publication.

Checker publie-t-il des articles ou soumet-il les données saisies ?

Non, Checker est une feuille de calcul qui calcule dans le navigateur. Ne pas créer de contenu Ne connectez pas de comptes, ne définissez pas de planning et ne publiez pas de publications.

Quelle place ANKK occupe-t-il dans ce flux de travail ?

Je suis Minho Jung, l'administrateur d'ANKK. ANKK n'est pas un outil de création d'IA intégré. Ce service connecte du contenu préparé par des humains, des outils d'IA externes ou des scripts. compatible avec le réglage de l'heure État de la destination par canal et vérification du fournisseur d'origine

Le Checker gratuit est un outil de prise de décision distinct qui s'exécute dans le navigateur, tandis qu'ANKK est une couche de travail pour une republication régulière. qui doit suivre le contenu, le travail et les preuves du fournisseur en un seul flux

Voir le workflow de planification et de vérification du provider original dans ANKK

Liste de contrôle finale avant de réessayer

  • Enregistrer la date, l'heure et Asia/Bangkok terminé ?
  • Est-il correct de convertir en UTC ?
  • le content ID, le job ID et l'ID de fournisseur ont-ils été séparés ?
  • Spécifiez un accusé de réception dont il n'est pas clair s'il est ambigu ou non.
  • Vérifiez les messages, les médias, les liens racine et de réponse séparément ou non.
  • Le fournisseur est-il initialement ouvert dans le bon compte ?
  • Limiter la récupération aux seules parties dont il a été prouvé qu'elles ne se sont pas encore produites ou non.

Si vous ne pouvez toujours pas répondre à toutes les questions. Conservez le statut comme validé ou « inconnu ». Il est préférable d'attendre des preuves plutôt que de recréer l'objet fournisseur sur la base de conjectures.