Récupérer l’historique des exécutions du Template cron

Renvoie les déclenchements conservés pour un Template Cron.

Définissez TEMPLATE_ID_OR_NAME sur un Template Cron appartenant au Workspace authentifié. Cet aperçu soumis à un contrôle d’accès renvoie jusqu’à 100 occurrences planifiées des 30 derniers jours, de la plus récente à la plus ancienne. Utilisez la valeur next_before de la réponse comme valeur de before pour récupérer des occurrences planifiées plus anciennes. Une valeur null signifie qu’il n’existe aucune occurrence planifiée plus ancienne encore conservée. Chaque entrée comprend l’heure prévue, l’heure d’admission et l’heure de fin, le résultat et un code de motif assaini. Les exécutions ignorées, qui se chevauchent, mises en pause ou ambiguës sont conservées aux côtés des Assemblies terminées. Un point de contrôle d’Assembly manquant passe à lost après le délai configuré, qui est de 10 minutes par défaut. Un point de contrôle initial d’Assembly reçu tardivement peut corriger ce résultat. Une Assembly planifiée qui plante est immédiatement marquée failed avec le motif crashed_not_retried. Elle ne fait l’objet d’aucune nouvelle tentative, et l’exécution planifiée suivante se déroule normalement. Le champ cron_disabled_reason de premier niveau explique un arrêt automatique de la planification actuelle : consecutive_failures signifie trois exécutions consécutives en échec ; auth_key_unavailable, instructions_invalid, schedule_invalid ou dispatch_rejected signifie un échec permanent de validation ou de distribution. Corrigez le problème et réactivez la planification pour reprendre les exécutions. Cette explication persiste au-delà de l’historique de 30 jours. La réactivation ou la modification des paramètres de planification crée une nouvelle révision de la planification et efface cette explication. Une valeur null ou absente signifie qu’aucune explication n’est disponible ; elle ne permet pas de déterminer si la planification est activée ou en pause. Les informations d’identification et les Instructions stockées ne sont jamais incluses dans cette réponse.

Exemple de requête

Définissez TEMPLATE_ID_OR_NAME sur la valeur de votre ressource sans l’encoder en pourcentage.

Exécutez cette requête dans un shell côté serveur avec curl et un jeton porteur approprié dans TRANSLOADIT_TOKEN. Si vous avez besoin d’un jeton, développez la section de configuration ci-dessous.

if ! TOKEN_RESPONSE="$(curl --fail-with-body -sS \
  --request POST \
  --url 'https://api2.transloadit.com/token' \
  --user "${TRANSLOADIT_KEY:?Set TRANSLOADIT_KEY}:${TRANSLOADIT_SECRET:?Set TRANSLOADIT_SECRET}" \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'aud=api2' \
  --data-urlencode 'scope=templates:read')"; then
  printf '%s\n' "$TOKEN_RESPONSE" >&2
  exit 1
fi
TRANSLOADIT_TOKEN="$(printf '%s' "$TOKEN_RESPONSE" |
  jq -er '.access_token | strings | select(length > 0)')" || exit 1

curl --fail-with-body -sS --request GET --get \
  --url "https://api2.transloadit.com/templates/${TEMPLATE_ID_OR_NAME:?Set TEMPLATE_ID_OR_NAME}/cron-runs" \
  --header "Authorization: Bearer ${TRANSLOADIT_TOKEN:?Set TRANSLOADIT_TOKEN}" \
  --data-urlencode 'params={}'

Ce point de terminaison accepte des params signés ou un jeton porteur. Consultez la section Authentification pour les instructions de configuration.

Portée requise pour l’Auth Key ou le jeton porteur : templates:read.

Les requêtes signées nécessitent à la fois une signature et un horodatage params.auth.expires situé dans le futur. Les jetons porteurs ne nécessitent ni l’un ni l’autre.

Les champs d’authentification de cette liste s’appliquent aux requêtes signées. Avec un jeton porteur, vous pouvez omettre params.auth et le champ distinct signature. Comparez les paramètres de requête spécifiques à l’authentification ci-dessous.