Vulnerability in EPiServer.Forms
We have a rather urgent problem with episerver forms. About 50% of the time emails don't get send. The production has a loadbalancer with two servers. The customer has like 10 online forms that uses a custom actor that inherits from SendEmailAfterSubmissionActor and a service that inherits from ActorsExecutingService. We're using Episerver 9 and forms 3.0.0.
From what I can see the custom actor does get found in the service, but the actor models not. This works well in all environments except production (also being the only one being loadbalanced), therefore we have no way of debugging it. The 50% fail also seems to be totally random regarding type of form and with or without attachment.
Very, very simplified code:
public class FormsSubmissionService : ActorsExecutingService
public override IEnumerable GetFormSubmissionActors(
, FormContainerBlock formContainer
, FormIdentity formIden
, HttpRequestBase request
, HttpResponseBase response
, Guid permanentFormSubmissionId, bool isFormFinalizedSubmission)
var actors = base.GetFormSubmissionActors(submission, formContainer, formIden, request, response, permanentFormSubmissionId, isFormFinalizedSubmission).ToList();
var customEmailActors = actors.OfType();
// This actor is always found
var ourCustomActor = customEmailActors.FirstOrDefault();
// Here it goes wrong, half of the time doesn't find the actor models
var actorModel = ourCustomActor.Model as IEnumerable;
Does anyone know what could cause this or have a similar experience (with a solution)?
There is a bug relate to it. The bug is fixed in version 4.2.2 or 4.4.3, please upgrade the add-on and see if it work.
Hi Dac, I'm happy to hear it's a bug and that its fixed. We were already looking into upgrading episerver forms, only any version >= 4.2.2 requires episerver 10. Even though we are busy moving to episerver 10 this takes a bit more effort and I was really hoping - because of the severity of the problem - that there would also have been a fix for episerver 9.
Anyway thanks for your answer
Sorry for the problem.
It's true that the fix is for Forms 4.2.2 (which is a hotfix) and Forms 4.4.3+.
If working on CMS9 is crucial with you, please file a SupportCase (though we really do encourage you to use the latest version of Forms, v4.4.3)
Thanks Thach, We're already busy to make a quick move to 10. We also believe in staying with the latest versions, so we're quite happy to make the move . Anyway good to know that the possibility to file a supportcase excists
We have been experiencing the same issue. good to hear that this has been fixed!
However, today we upgraded to 4.2.2 (we are using CMS 10.3.1) but the issue is still there. Anything else we might be missing here?
Hi Reinder, Sounds a bit worrying. We have just upgraded to episerver 10 and latest version of forms, but we are still in acceptance and it will go to production in 2 weeks. I will update this post with our results
Hi Reinder Wit, can you create a Support Case?
We have created the 4.2.2 (hotfix package) for other customer and it solved their problem.
If possible, please go to v4.4.4
Hi Asa Alvebrand, please bump directly to the 4.4.4 (mainstream package) if possible.
Thanks THACH Lockevn,I've upgraded to 4.2.2 now, and I'm working on getting this deployed so I can test it.Will let you know if this solves the issue.
We have upgraded to the latest version, 4.4.4, but unfortunately we cannot reproduce the issue on our test & acceptance environment. So at the moment, I cannot be sure if this will fix it. We will have to dig deeper into why emails on production are not always sent out.
Hi, if you cannot reproduce the issue, why don't you deploy 4.4.4 to production?
We have fixed bug http://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=AFORM-955 and the other partner reported (last month) that it's fine with 4.2.2 and 4.4.1.
we will be deploying the upgraded version to production this wednesday if all goes well. But we could not reproduce it on acceptance even before we deployed the newer Forms version. So either it is a different issue, of we have differences between our production and acceptance environment.
Will keep you posted...
You can see in the bug, it is really hard to reproduce on test/staging. It happens intermittently on Azure (cloud).
IMO, it's not because of your "differences between our production and acceptance environment."
It's not different issue as well.
The root cause is:
it's not a good implementation of PropertyGenericList<T> (inside Forms). It inherits PropertyLongString, and try to parse (JSON deserialization) underlying string (actual saved value) to a cached IEnumerable<T>. And no lock for the parsing/caching.
In some rare cases (Azure, I guess ...) the first request does not populate/deserialize string value (I still don't know why), and it cache the IEnumerable<T>.Empty() as default value. Because nothing is updated in EditView, it keeps the Empty value all the time.Because it is nearly impossible to reproduce it in development environment, we fix by rewriting it, and remove the cache of deserialization result.
The SelectionBaseElement's Items and and EmailActor's RecipientConfiguration use PropertyGenericList<T> to render the UI for Editor.
Email sending feature of EmailActor does not see recipients in its configuration, so it does nothing.