Ausführungsverlauf des Cron-Templates abrufen

Gibt aufbewahrte Ticks für ein Cron-Template zurück.

Setzen Sie TEMPLATE_ID_OR_NAME auf ein Cron-Template, das dem authentifizierten Workspace gehört. Diese zugriffsgeschützte Vorschau gibt bis zu 100 Ticks aus den vergangenen 30 Tagen zurück, beginnend mit den neuesten. Verwenden Sie den Wert next_before aus der Antwort als before, um ältere Ticks abzurufen. Ein null-Wert bedeutet, dass keine älteren Ticks mehr vorgehalten werden. Jeder Eintrag enthält den geplanten Zeitpunkt, die Zeitpunkte der Zulassung und des Abschlusses, das Ergebnis sowie einen bereinigten Ursachencode. Übersprungene, sich überschneidende, pausierte und mehrdeutige Läufe werden neben abgeschlossenen Assemblies vorgehalten. Ein fehlender Assembly-Checkpoint erhält nach der konfigurierten Zeitüberschreitung, die standardmäßig 10 Minuten beträgt, den Status lost. Ein verspäteter erster Assembly-Checkpoint kann dieses Ergebnis korrigieren. Eine abgestürzte, planmäßig gestartete Assembly wird sofort als failed mit dem Grund crashed_not_retried markiert. Sie wird nicht erneut ausgeführt, und der nächste geplante Lauf findet wie gewohnt statt. Der übergeordnete Wert cron_disabled_reason erklärt eine automatische Deaktivierung des aktuellen Zeitplans: consecutive_failures bedeutet drei aufeinanderfolgende fehlgeschlagene Läufe; auth_key_unavailable, instructions_invalid, schedule_invalid oder dispatch_rejected bedeutet einen dauerhaften Validierungs- oder Dispatch-Fehler. Beheben Sie das Problem und aktivieren Sie den Zeitplan erneut, um fortzufahren. Diese Erklärung bleibt über den 30-Tage-Verlauf hinaus verfügbar. Wenn Sie den Zeitplan erneut aktivieren oder die Zeitplaneinstellungen ändern, beginnt eine neue Revision des Zeitplans und die Erklärung wird gelöscht. Ein null-Wert oder ein fehlender Wert bedeutet, dass keine Erklärung verfügbar ist; daraus lässt sich nicht ableiten, ob der Zeitplan aktiviert oder pausiert ist. Zugangsdaten und gespeicherte Instructions sind in dieser Antwort niemals enthalten.

Beispielanfrage

Setzen Sie TEMPLATE_ID_OR_NAME auf den Wert Ihrer Ressource, ohne ihn prozentzukodieren.

Führen Sie diese Anfrage in einer serverseitigen Shell mit curl und einem geeigneten Bearer-Token in TRANSLOADIT_TOKEN aus. Wenn Sie ein Token benötigen, klappen Sie die folgende Einrichtung auf.

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={}'

Dieser Endpunkt akzeptiert signierte params oder ein Bearer-Token. Anweisungen zur Einrichtung finden Sie unter Authentifizierung.

Erforderlicher Berechtigungsumfang für Auth Key oder Bearer-Token: templates:read.

Signierte Anfragen erfordern sowohl eine signature als auch einen in der Zukunft liegenden Zeitstempel für params.auth.expires. Bearer-Tokens erfordern keines von beiden.

Die Authentifizierungsfelder in dieser Liste gelten für signierte Anfragen. Mit einem Bearer-Token können Sie params.auth und das separate Feld signature weglassen. Vergleichen Sie unten die Anfrageparameter der einzelnen Authentifizierungsmethoden.