Episerver Forms: No EmailTemplateActorModel found for custom emai

Episerver Forms: No EmailTemplateActorModel found for custom email actor

Asa Alvebrand

Vote:

Hi,

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(
		Submission submission
		, 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)?

thanks,

Asa

#176395

Mar 17, 2017 16:10

Dac Thach Nguyen

Vote:

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.

#176462

Edited, Mar 20, 2017 4:09

Asa Alvebrand

Vote:

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

#176473

Mar 20, 2017 10:37

Thach

Vote:

Hi Asa,

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+.

this issue was reported and found recently
Forms works with CMS10 for quite a long time
and we only fix bug in the newest major branch (CMS10-compatible).

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)

#176474

Mar 20, 2017 10:43

Asa Alvebrand

Vote:

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

#176476

Mar 20, 2017 11:14

Reinder Wit

Vote:

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?

#177274

Apr 06, 2017 15:47

Asa Alvebrand

Vote:

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

#177293

Apr 06, 2017 18:19

Thach

Vote:

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.

#177310

Apr 07, 2017 6:35

Reinder Wit

Vote:

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.

#177313

Edited, Apr 07, 2017 8:16

Reinder Wit

Vote:

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.

#177347

Apr 10, 2017 9:04

Thach

Vote:

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.

#177348

Apr 10, 2017 9:14

Reinder Wit

Vote:

Hey,

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...

#177349

Apr 10, 2017 9:18

Thach

Vote:

Yes :)

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.

#177351

Apr 10, 2017 9:29