Hallo zusammen,
wir sind hier nicht der Threadstarter, klinken uns aber mit eigenen Beobachtungen ein — Morimus' Checkliste (v1-Pfad/api-version, JSON-Zahlentypen, drei Testfälle, Proxy vs. direkt, gewährte Scopes, OpenAPI-Abgleich) passt nämlich verblüffend genau auf ein Problem, das wir seit ein paar Tagen unabhängig davon bei einem ganz anderen Endpunkt haben: POST/PATCH /items/{itemId}/suppliers (Lieferantenzuordnung) liefert bei uns durchgehend HTTP 400 ValidationError, obwohl alle gesendeten Werte eindeutig im laut Fehlermeldung selbst angegebenen gültigen Bereich liegen. Also vermutlich derselbe Bug-Familie wie WAWI-87918, nur an anderer Stelle als bei /salesOrders/{id}/lineitems.
Da die Checkliste so präzise auf unseren Fall passte, haben wir sie komplett durchgetestet — vielleicht hilft das bei der Eingrenzung, auch wenn unser Setup (kein Lovable/Cloudflare, direkter Server-Zugriff) ein anderes ist als das des Threadstarters:
1. Rohrequest protokolliert (Methode, vollständiger Pfad, api-version, Content-Type, JSON-Body):
Code:
POST /items/15137/suppliers
api-version: 1.0 | Content-Type: application/json
Body: {"SupplierId":1}
-> HTTP 400
{"ErrorCode":"ValidationError", ... "ErrorMessage":"Validation failed"}
2. /v1/-Pfad gleichzeitig mit api-version-Header: Getestet in allen fünf Kombinationen — /items/... und /v1/items/..., jeweils mit api-version: 1.0, api-version: 1 und ganz ohne den Header. Alle fünf liefern identisch HTTP 400 mit derselben Errors-Liste. Kein Zusammenhang bei uns.
3. Zahlen als echte JSON-Zahlen statt String/null: War bei uns von Anfang an korrekt — der Body enthält durchgehend echte JSON-Zahlen ({"SupplierId":1}, kein "1" oder null), verifiziert am rohen, unmittelbar vor dem Request erzeugten Payload.
4. Die drei vorgeschlagenen Vergleichsfälle, alle mit vollständigem Rohrequest protokolliert:
- POST nur mit SupplierId: {"SupplierId":1} → HTTP 400, identische Fehlerliste.
- POST mit allen beanstandeten Zahlenfeldern explizit als 0: {"SupplierId":1,"TaxRate":0,"Stocklevel":0,"DeliveryTime":0,"PurchasePriceNet":0,"AmountPackagingUnit":0,"MinimumPurchaseQuantity":0,"PermissibleOrderQuantity":0} → HTTP 400, identische Fehlerliste (also wird selbst der explizit gültige Wert 0 durchgehend als außerhalb des Bereichs "0 und 2147483647" abgelehnt).
- PATCH einer bestehenden Zuordnung mit unveränderten, unmittelbar zuvor per GET gelesenen Werten: Erst GET /items/15132/suppliers (liefert eine seit Wochen bestehende, funktionierende Zuordnung mit realen Werten wie PurchasePriceNet: 4.72, TaxRate: 19), direkt im Anschluss dieselben Werte unverändert per PATCH /items/15132/suppliers/1 zurückgeschrieben → ebenfalls HTTP 400, identische Fehlerliste.
5. Anfrage über Proxy/CDN vs. direkt gegen den Wawi-Server: Bei uns kommt kein Lovable/Cloudflare oder ähnlicher Zwischen-Layer zum Einsatz — wir sprechen die Wawi-REST-API direkt über die feste Server-IP an (https://<IP>:5883/api/eazybusiness), ohne Proxy dazwischen. Ein Cloudflare-/CDN-bedingter Unterschied scheidet bei uns also als Ursache aus.
6. Tatsächlich gewährte Scopes (nicht nur angeforderte): Explizit geprüft — eigene, neue App-Registrierung durchgeführt (POST /authentication), in der Wawi freigeschaltet, Status per GET /authentication/{registrationId} abgefragt. Das GrantedScopes-Feld der Antwort enthält nachweislich item.createitemsupplier und item.updateitemsupplier. Mit dem so erhaltenen, frischen Token (eigene x-appid, eigener ApiKey) schlägt derselbe Request identisch fehl — Scope-Problem damit ausgeschlossen.
7. Abgleich mit dem lokalen OpenAPI-Schema: CreateItemSupplier laut /swagger/v1/swagger.json verlangt nur SupplierId als Pflichtfeld, alle beanstandeten Felder (TaxRate, Stocklevel, DeliveryTime, PurchasePriceNet, AmountPackagingUnit, MinimumPurchaseQuantity, PermissibleOrderQuantity) sind laut Schema optional, jeweils type: number/format: decimal bzw. bei DeliveryTime type: integer/format: int32. Unser gesendeter Payload entspricht dem Schema exakt (Typen und Pflichtfeld stimmen überein) — die serverseitige Validierung weicht davon ab.
Fazit unsererseits: Alle sieben Prüfpunkte durchlaufen, keiner erklärt oder behebt das Verhalten bei uns. Das Muster "gültiger, im Schema erlaubter Wert (auch 0) wird trotzdem als außerhalb des Bereichs abgelehnt" passt tatsächlich zum von euch vermuteten Zusammenhang mit der fehlerhaften v1-Modellvalidierung — bei uns ist es nur ein anderer Endpunkt (/items/{id}/suppliers statt /salesOrders/{id}/lineitems). Vielleicht hilft das als zweiter unabhängiger Beleg, dass es sich um ein grundsätzlicheres Validierungsproblem in diesem Wawi-Build handelt und nicht um einen isolierten Einzelfall an einem Endpunkt.
Wir stehen für weitere Tests gerne zur Verfügung, falls das bei der Eingrenzung hilft.
