Zum Inhalt springen

Could not ultimately dispatch the request after 101 iterations

Erstellt am 5. Januar 2012 · 9 Antworten · letzte Antwort am 3. Juli 2014

Tags: Frage

BFSven ·

Heute mal keine Frage sondern eine Erkenntnis.

Folgende Fehlermeldung ist sicher allen Formularwütigen schon einmal untergekommen:

#1217839467: Could not ultimately dispatch the request after 101 iterations. Most probably, a @dontvalidate annotation is missing on re-displaying a form with validation errors.

Eigentlich eine aussagekräftige Exception. Die erste Annahme also ist: Es wird in der Ziel-Action eine Validierung ausgeführt, diese schlägt fehl und in der referrer-Action fehlt ein "@dontvalidate $formular".

Was aber, wenn diese Annotation da ist und man sich nen Wolf sucht (so wie ich gestern).
2. Möglichkeit: Wie Christian Bleichner schreibt, kann es auch an zu vielen Verschachtelungen liegen, die Maximalanzahl kann man mit

max_input_nesting_level = 64
xdebug.max_nesting_level = 100

in der php.ini hochsetzen.

Wenn das auch nicht funktioniert (so wie bei mir), gibt es noch mindestens eine weitere Möglichkeit:
3. Die Properties matchen nicht: Im Formular gab es bei mir ein "startDateAsString"*, für die es im Model eine get-Methode gab, aber halt keine setter. Eigentlich ein einfacher Fehler, wenn man denn durch die Fehlermeldung nicht auf eine falsche Fährte gebracht würde.
Warum er dann in einen Infinite-Loop geht, hab ich noch nicht genauer untersucht. Was bleibt, ist die Erkenntnis, dass Fehlermeldungen in Extbase und Fluid manchmal unglaublich *arrrghh* sind #paralyzed# und dass mal die Properties im Formular nochmal genauer prüfen sollte.

Beste Grüße,
Sven

* mein startDate im Model ist eine DateTime, welche weitere Möglichkeit habe ich, es formatiert auszugeben, wenn es mit <f:form.textbox property="startDate" /> eingebunden ist?

Jan.​S ·

Möglichkeit Nr.4

Ich erwarte in der createAction ein Objekt welches ich nicht als argument übergeben habe. In diesen Fall bekommt man wohl auch zu einer infinitely loop. #evil#

karf ·

Wenn du den neuen PropertyMapper benutzt, ist die richtige Annotation nicht mehr "@dontvalidate $forumlar" sondern "@ignorevalidation $formular". (Auch wenn in der Fehlermeldung weiterhin @dontvalidate steht ...)

bberger ·

Oh, dankeschön.

Man sollte ein Ticket eröffnen mit der Bitte die Fehlermeldung etwas aussagekräftiger bzw. zumindest weniger irreführend zu gestalten..

MajPay ·

Noch eine (wahrscheinlich eher selten auftretende Möglichkeit):
Man cached das Reflection Backend per memcache, dieser wird anscheinend nicht geflushed, wenn man den globalen Cache oder den Konfigurations Cache leert. Dann ist die Fehlermeldung sogar ausnahmsweise korrekt und man sucht sich dumm und dämlich.

Unbekannter Benutzer ·

2. Möglichkeit: Wie Christian Bleichner schreibt, kann es auch an zu vielen Verschachtelungen liegen...

Das kann eigentlich kein Grund sein, dann sollte PHP eine dementsprechende Fehlermeldung werfen.

3. Die Properties matchen nicht

Das wiederum kann eigentlich nur ein Problem sein, wenn ich das Formular mit der selben Action darstelle and die ich es auch abschicke. Laut allen Tutorials und Manuals sollte man das eben nicht machen.

4. Das ist natürlich dann ein ein Problem das im CachingFramework gelöst werden müsste.

Jann0r ·

Es reicht nicht, fuer die Action das @dontvalidate zu setzen.
Wenn man im Model das fuer die Properties zusaetzlich setzt, funktionierts...

cephei ·

Bei mir lags an Punkt 3. Danke für den Hinweis.
Also immer genau prüfen, dass alle Variablen + Get/Set Methoden vorhanden sind!

bennof ·

In meinem Fall hatte ich schlicht einen Schreibfehler in den Property-Namen im Fluid-Formular.
Die Namen der Formularfelder im Fluid-Template haben nicht mit den Property-Namen bzw. den Gettern und Settern der Modell-Klasse übereingestummen. Korrigiert und alles läuft bestens!