Handlebars.Net: IndexOutOfRangeException at FixedSizeDictionary`3.AddOrReplace
Getting this exception periodically in Handlebars, Version=2.1.0.0 trying to render content from a compiled delagate (HandlebarsTemplate<object, object>)
Not sure what else I can provide because it doesn’t seem related to the content being rendered. Debugging though it always works.
We were previously using 2.0.9 on .NET 5. We upgraded our project to .NET 6.0 and Handlebars 2.1.0 and the problem apparently started.
System.IndexOutOfRangeException:
at HandlebarsDotNet.Collections.FixedSizeDictionary`3.AddOrReplace (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at HandlebarsDotNet.BindingContext.Initialize (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at HandlebarsDotNet.BindingContext+BindingContextPool.CreateContext (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at HandlebarsDotNet.BindingContext.Create (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at HandlebarsDotNet.HandlebarsEnvironment+<>c__DisplayClass15_0.<Compile>b__0 (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at HandlebarsDotNet.HandlebarsEnvironment+<>c__DisplayClass16_0.<Compile>b__0 (Handlebars, Version=2.1.0.0, Culture=neutral, PublicKeyToken=22225d0bf33cd661)
at OnSend.MessagingService.Core.Templating.HandlebarsMessageBuilder.BuildMessage (OnSend.MessagingService.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null: D:\a\1\s\OnSend.MessagingService.Core\Templating\HandlebarsMessageBuilder.cs:68)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 47 (15 by maintainers)
Commits related to this issue
- Merge pull request #512 from Handlebars-Net/issues/498 Fix collision handling in`FixedSizeDictionary` — committed to Handlebars-Net/Handlebars.Net by oformaniuk 2 years ago
It’s been in the staging environment for a week without issue. It’s rolling out a bit broader in the next couple days. I’ll let you know what I see.
That’s great news. I will be happy to try out the new code during our next deployment.
@pavisalavisa I suspected something similar in my case, but the AWS documentation makes it pretty clear that lambda execution environments can only run one function invocation at a time. If this is the case, static resources are not shared accross parallel lambda invocations, although they are generally shared accross consecutive invocations, because the same lambda execution environment is reused whenever possible.
Also, I never observed such a thing as a “corrupted” resource pool. I actually never observed the event twice in the same week, without having to restart anything. Maybe the execution environment is recycled if the function errors out. Maybe I could investigate this further by testing the “shared static resources” by activating tracing of static random variables and running a small load test, though I’m not sure I will have the time to do so.
Perfect, I’ll get it checked in to our staging environment tomorrow, and that should roll out next week, so I should be able to report back in 7-8 days from now.
We just had the same issue on a .NET 6 program too. We tried everything without understanding this behavior. We just restart our service and all worked after that. Let me know if you need some input, but actually we don’t have so much to provide to you.
Here is our stack :
Sorry to spam the thread so much, but I’m running this fork https://github.com/ChadNedzlek/Handlebars.Net/commit/4f42cdaed3730d1dae6b6c52fe56e3693e5223bc in my service in one of our staging environments for a while to see if I can figure out if what I suspect is happening is happening, and, if so, where (since the exception I added should have the double return on the stack)
Hi. For your information, we have been monitoring our test environment on .NET 6.0 + 2.0.9 for several days and have not seen the ‘IndexOutOfRangeException’ occur again.
We have deployed this configuration into production as of now.
Next step is to see if we can get the ‘IndexOutOfRangeException’ to occur again in the test environment on 2.1.0 and provide a debug stack trace.