Virtual Happy Hour this month, Jun 28, we'll be getting a sneak preview at our soon to launch SaaS CMS!

Try our conversational search powered by Generative AI!

Episerver Forms: No EmailTemplateActorModel found for custom email actor

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
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
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
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
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 smile. Anyway good to know that the possibility to file a supportcase excists

#176476
Mar 20, 2017 11:14
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
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
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
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
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
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
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
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
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.