DokumentationCommerceTools

ACP2E-5122: Verarbeitete GraphQL-Warenkorbfehler werden fälschlicherweise in das Ausnahmeprotokoll geschrieben

Letzte Aktualisierung: 21. Oktober 2026

Erstellt für:

  • Experienced
  • Admin
  • Developer

Mit dem Patch ACP2E-5122 wird das Problem behoben, dass behandelte GraphQL-Warenkorbanfragefehler als Anwendungsfehler in das Ausnahmelogo geschrieben werden. Dieser Patch ist verfügbar, wenn Quality Patches Tool (QPT) 1.1.84 installiert ist. Die Patch-ID lautet ACP2E-5122. Dieses Problem wird voraussichtlich in Adobe Commerce 2.4.10 behoben.

Betroffene Produkte und Versionen

Der Patch wird für die Adobe Commerce-Version erstellt:

  • Adobe Commerce (alle Bereitstellungsmethoden) 2.4.8-p5

Kompatibel mit Adobe Commerce-Versionen:

  • Adobe Commerce (alle Bereitstellungsmethoden) 2.4.4 - 2.4.9
NOTE
Der Patch könnte mit neuen Quality Patches Tool-Versionen auch für andere Versionen gelten. Um zu überprüfen, ob der Patch mit Ihrer Adobe Commerce-Version kompatibel ist, aktualisieren Sie das magento/quality-patches auf die neueste Version und überprüfen Sie die Kompatibilität auf der Seite Quality Patches Tool: Nach Patches suchen. Verwenden Sie die Patch-ID als Suchbegriff, um den Patch zu finden.

Problem

Behandelte GraphQL-Warenkorbanfragefehler werden als Anwendungsfehler in das Ausnahmelog geschrieben.

Schritte zur Reproduktion:

  1. Senden Sie eine GraphQL placeOrder-Mutation mit einer ungültigen, abgelaufenen oder bereits zerstörten maskierten Warenkorb-ID wie diese Mutation:

    code language-none 
        mutation {
        placeOrder(input: { cart_id: "test" }) {
            orderV2 {
                id
                number
            }
        }
    }

  2. Überprüfen Sie die GraphQL-Antwort.

  3. Überprüfen Sie var/log/exception.log auf den Fehler beim Warenkorb.

Erwartete Ergebnisse:

  1. Die GraphQL-Anfrage gibt eine verarbeitete Client-seitige Fehler-Payload für den ungültigen Warenkorb ohne eine HTTP 500-Antwort zurück.
  2. Die behandelte GraphQlNoSuchEntityException wird nicht in var/log/exception.log geschrieben und stattdessen in einen Protokollkanal mit niedrigerem Schweregrad weitergeleitet.

Tatsächliche Ergebnisse:

Jede Anfrage schreibt die behandelte Ausnahme in var/log/exception.log mit report.ERROR Schweregrad, was bei wiederholten Anfragen zu unbegrenztem Protokollwachstum führt.

Patch anwenden

Verwenden Sie je nach Bereitstellungsmethode die folgenden Links, um einzelne Patches anzuwenden:

Verwandtes Lesen

Weitere Informationen zu Quality Patches Tool finden Sie unter:

recommendation-more-help
commerce-operations-help-tools