GraphQL-Fehler

​

Resolver-Fehler kommen mit HTTP 200 an

// FALSCH - behandelt eine fehlgeschlagene Anfrage als Erfolg
if (response.ok) {
  return "everything worked";
}

if (!response.headers.get("content-type")?.includes("json")) {
  throw new Error(`GraphQL request failed with HTTP ${response.status}`);
}

const result = await response.json();

if (result.errors) {
  for (const error of result.errors) {
    // Vor der Ausführung abgefangene Fehler haben keine extensions, daher sicher lesen.
    console.log(error.message, error.extensions?.status);
  }
}

• Eine fehlerhafte Anfrage gibt einen Fehlerstatus zurück: HTTP 400 bei ungültigem JSON oder fehlender query, 413 bei einem Body über 64 KB, 405 bei einer anderen Methode als POST und 415 bei einem nicht unterstützten Content-Type.
• Eine Query, die für das Schema nicht gültig ist, gibt nur dann HTTP 400 zurück, wenn Ihre Anfrage Accept: application/graphql-response+json sendet. Das betrifft Syntaxfehler, unbekannte Felder, falsche Argumenttypen, ungültige Enum-Werte und Queries, die die Abfragelimits überschreiten. Wenn Sie Accept: application/json oder keinen Accept-Header senden, gibt derselbe Fehler HTTP 200 zurück. In beiden Fällen enthält der Body ein errors-Array und kein data.

​

Die Fehlerstruktur

{
  "data": { "postHistory": null },
  "errors": [
    {
      "message": "Rate limit exceeded",
      "path": ["postHistory"],
      "extensions": {
        "status": 429,
        "retryAfter": 7
      }
    }
  ]
}

• message – eine lesbare Beschreibung. Wir entfernen API Keys und andere Zugangsdaten aus Resolver-Fehlermeldungen, aber ein Fehler zu einem von Ihnen gesendeten Wert, etwa einer Variablen mit falschem Typ, kann diesen Wert wiederholen. Behandeln Sie message als potenziell sensibel, bevor Sie sie protokollieren.
• path – welches Feld in Ihrer Query fehlgeschlagen ist. Bei mehreren Feldern in einer Anfrage erkennen Sie daran, welches betroffen ist.
• extensions.status – der HTTP-Status, den der entsprechende REST-Aufruf zurückgegeben hätte. Verzweigen Sie anhand dieses Werts.
• extensions.code – der numerische Ayrshare-Fehlercode, sofern der zugrunde liegende Endpunkt einen liefert.
• extensions.retryAfter – vorhanden bei Upstream-429-Fehlern wegen Kontingent oder Rate-Limit, wenn eine Wartezeit für die Wiederholung verfügbar ist. Beim 429 des Dispatch-Budgets pro Anfrage ist es nicht vorhanden.

​

Teilerfolg

{
  history: postHistory(lastDays: 7)
  analytics: socialAnalytics(platforms: [INSTAGRAM])
}

{
  "data": {
    "history": { "history": [{ "id": "RkQ8uXg2jT7bNd1Wq0Ya", "status": "success", "post": "Hello world" }], "refId": "9d2a7c41f0b8e6d35a1c", "count": 1, "lastUpdated": "2026-09-24T12:00:00.000Z", "nextUpdate": "2026-09-24T12:00:00.000Z" },
    "analytics": null
  },
  "errors": [
    {
      "message": "Rate limit exceeded",
      "path": ["analytics"],
      "extensions": { "status": 429 }
    }
  ]
}

​

Teilerfolg bei Beiträgen in mehreren Netzwerken

mutation {
  createPost(input: {
    post: "Hi"
    platforms: [FACEBOOK, INSTAGRAM]
    idempotencyKey: "multi-network-hi-001"
  }) {
    status
    postIds { platform postUrl }
    errors { platform message code }
    blocked { platform message }
  }
}

• postIds – Netzwerke, in denen veröffentlicht wurde, mit ihren Beitrags-URLs. Nur Erfolge.
• errors – Netzwerke, in denen es fehlgeschlagen ist, mit dem Grund.
• blocked – Netzwerke, die vor einem Versuch gestoppt wurden, zum Beispiel durch den netzwerkspezifischen Circuit Breaker nach wiederholten deterministischen Fehlern. Diese sind getrennt von Anbieterversuchen, die Fehler zurückgegeben haben.

​

Wiederholungen

​

Häufige Statuswerte