While looking at another report, we had an insight into an unusual circumstance which is probably at the bottom of your problem here. Tomorrow's builds (5.0p and greater) will contain a fix for that issue - please try it and let us know.
Announcement
Collapse
No announcement yet.
X
-
While looking into the causes of intermittently failing automated tests during our preparations for the recent release of 6.1 / 11.1, we discovered a case in which the __cachedType could still be used inappropriately, giving rise to the possibility of incorrectly inheriting validations from includeFrom fields. The fix for this should have gone into 5.0 and greater, but because this was discovered during a crunch time for release, that was overlooked and it only got committed on the 6.1 branch. This fix has now been backported as far as 5.0 / 10.0.
Edit: Sorry, to be clear, this change will be present in 5.0 / 10.0 and greater builds as of tomorrow's builds, those dated 8th JulyLast edited by Isomorphic; 7 Jul 2017, 05:29. Reason: Adding the build date when the fi can be expected
Comment
-
Hi Isomorphic,
that's great to here. I'll try the new build then. Then is back to #17:
I will try and hopefully in a few months only report back that the issue did not occur again.
Thanks a lot & Best regards
Blama
Comment
-
Hi Isomorphic,
just to let you know: The bug did not occur again in the last months, where I also only had a few restarts. So even with the long Tomcat-uptime, it did not occur again.
Lets assume and hope then that those changes did the trick.
Thank you & Best regards
Blama
Comment
-
Hi Isomorphic,
this is happening again for me (v11.1p_2018-05-07) and seems to come from the server (request is sent and returns with a validation error). Before I was using an early April build, which did not have this issue.
It happens for two tables and also after a restart, so I assume this is not related to the caching issue it was before.
Were there some changes in this area?
Thank you & Best regards
BlamaLast edited by Blama; 19 Jun 2018, 04:59.
Comment
-
This turned out to be a validator run on a customSelectExpression field. It had length="10", but the value was up to 13 chars long, which resulted then in the validation error.
IMHO fields with customSelectExpression should not go though validation, but I could not reproduce the behavior.
For me, the issue does not matter so much, because I will take care now that the length matches the max length of the cSE-return value.
Best regards
Blama
Comment
Comment