Null pointer exception on actor initialization (when using F#)
Expected Behavior
I have a service that registers an actor. On dapr run the service should start without errors.
Actual Behavior
With the following command:
dapr run --app-id actors --app-port 3000 dotnet run
A null pointer exception is thrown:
== APP == Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'fieldName')
== APP == at System.Reflection.Emit.FieldBuilder..ctor(TypeBuilder typeBuilder, String fieldName, Type type, Type[] requiredCustomModifiers, Type[] optionalCustomModifiers, FieldAttributes attributes)
== APP == at System.Reflection.Emit.TypeBuilder.DefineFieldNoLock(String fieldName, Type type, Type[] requiredCustomModifiers, Type[] optionalCustomModifiers, FieldAttributes attributes)
== APP == at System.Reflection.Emit.TypeBuilder.DefineField(String fieldName, Type type, Type[] requiredCustomModifiers, Type[] optionalCustomModifiers, FieldAttributes attributes)
== APP == at Dapr.Actors.Builder.MethodBodyTypesBuilder.BuildRequestBodyType(ICodeBuilderNames codeBuilderNames, CodeBuilderContext context, MethodDescription methodDescription)
== APP == at Dapr.Actors.Builder.MethodBodyTypesBuilder.Build(ICodeBuilderNames codeBuilderNames, CodeBuilderContext context, MethodDescription methodDescription)
== APP == at Dapr.Actors.Builder.MethodBodyTypesBuilder.Build(InterfaceDescription interfaceDescription)
== APP == at Dapr.Actors.Builder.ActorCodeBuilder.BuildMethodBodyTypes(Type interfaceType)
== APP == at Dapr.Actors.Builder.ActorCodeBuilder.Dapr.Actors.Builder.ICodeBuilder.GetOrBuildMethodBodyTypes(Type interfaceType)
== APP == at Dapr.Actors.Builder.MethodDispatcherBuilder`1.Build(InterfaceDescription interfaceDescription)
== APP == at Dapr.Actors.Builder.ActorCodeBuilder.BuildMethodDispatcher(Type interfaceType)
== APP == at Dapr.Actors.Builder.ActorCodeBuilder.Dapr.Actors.Builder.ICodeBuilder.GetOrBuilderMethodDispatcher(Type interfaceType)
== APP == at Dapr.Actors.Builder.ActorCodeBuilder.GetOrCreateMethodDispatcher(Type actorInterfaceType)
== APP == at Dapr.Actors.Communication.ActorMethodDispatcherMap..ctor(IEnumerable`1 interfaceTypes)
== APP == at Dapr.Actors.Runtime.ActorManager..ctor(ActorService actorService)
== APP == at Dapr.Actors.Runtime.ActorRuntime.RegisterActor[TActor](Func`2 actorServiceFactory)
== APP == at [email protected](ActorRuntime actorRuntime) in /home/akkie/projects/dapr-vote/actors/Program.fs:line 18
== APP == at Dapr.Actors.AspNetCore.WebHostBuilderExtensions.UseActors(IWebHostBuilder hostBuilder, Action`1 configureActorRuntime)
== APP == at [email protected](IWebHostBuilder webBuilder) in /home/akkie/projects/dapr-vote/actors/Program.fs:line 15
== APP == at Microsoft.Extensions.Hosting.GenericHostBuilderExtensions.<>c__DisplayClass0_0.<ConfigureWebHostDefaults>b__0(IWebHostBuilder webHostBuilder)
== APP == at Microsoft.Extensions.Hosting.GenericHostWebHostBuilderExtensions.ConfigureWebHost(IHostBuilder builder, Action`1 configure)
== APP == at Microsoft.Extensions.Hosting.GenericHostBuilderExtensions.ConfigureWebHostDefaults(IHostBuilder builder, Action`1 configure)
== APP == at Actors.Program.CreateHostBuilder(String[] args) in /home/akkie/projects/dapr-vote/actors/Program.fs:line 13
== APP == at Actors.Program.main(String[] args) in /home/akkie/projects/dapr-vote/actors/Program.fs:line 26
Steps to Reproduce the Problem
Checkout https://github.com/PlanBGmbH/dapr-vote and execute the following command in the actors directory:
dapr run --app-id actors --app-port 3000 dotnet run
Method parameter names in F# interfaces are optional.
This declaration is valid but fails:
abstract Vote: Animal -> Task<Votes>
To workaround this issue, the method must be declared as:
abstract Vote: animal: Animal -> Task<Votes>
Thanks for sharing a workaround.
The dapr .net sdk only supports c# currently.
I'm starting to get into F# and would love to use it w/ Dapr. Are there any plans for a F# friendly package?
I'm starting to get into F# and would love to use it w/ Dapr. Are there any plans for a F# friendly package?
Thats would be a good addition, there are no plans to make a F# friendly package as of now, We would appreciate your contribution if you want to do a PR for it.
This seems like a bug that could be fixed though right? Is this a protocol limitation or just a bug in the IL generation code?
This seems like a bug that could be fixed though right? Is this a protocol limitation or just a bug in the IL generation code?
Yes, it can be seen as a bug when it comes to enabling F#. At this point core focus is to enable C# development and fix issues found for it.