Specifications and type for failure reasons

[malclear]

Hi Lutando,
I'm seeing that the "errors" parameter for the FailedExecutionResult has changed from an IEnumerable<string> to string[]. However, the type returned from WhyIsNotSatisfiedBy(T obj) in the Specification<T> class remains IEnumerable<string>. It is requiring that we now add ".ToArray( )" to our calls.
Was this intentional?

... new FailedExecutionResult(ourSpecification.WhyIsNotSatisfiedBy(command).ToArray());

Not a major issue, I think.

[Lutando]

Youre right, this is a breaking change that probably should not have happened. I'll make FailedExecutionResult support both and will will allocate memory for failure reasons there, its probably nicer if we allow it to also take in an IEnumerable and allocate in the ctor of FailedExecutionResult. My apologies for this 😅

[malclear]

No worries! I'm happy to help where I can.
In fact, before your next release, if you'd like me to build and test the Master branch against my codebase, I'd be glad to. Just let me know when you're about ready.

[malclear]

To append to this issue, and I've not figured out why it's happening, but in our unit tests if we use the ExpectMsg pattern, it fails with a timeout (even though I can see the aggregate code send the message): ExpectMsg<FailedExecutionResult>( ... ). However, if we use the Ask pattern for the call, it works! myManager.Ask<FailedExecutionResult>( ... )

This type of failure only happens with the latest 0.4.3 build.

[Lutando]

So in other words when you use a Tell(...) prior to ExpectMsg<FailedExecutionResult>( ... ) it doesn't work but when you use Ask<FailedExecutionResult> prior to ExpectMsg<FailedExecutionResult>( ... ) it does work?

[malclear]

Not quite... the first part of what you said is correct, but for my resolution, when I use Ask, I assign the result to a variable, ala: var result = await myManager.Ask<FailedExecutionResult>(myCommand), then that works.

[Lutando]

This smells like a quirk of akka.net's test kit. on the top of my head I'm not sure why the declaration and assignment would result in a positive test to be honest.

[Lutando]

Maybe I can find out why tomorrow 😁

[malclear]

ExpectMsg still works for the SuccessExecutionResult. It's only the FailedExecutionResult that requires the special handling. We can work around it, so no rush.

[Lutando]

very odd. Your previous comment actually makes me a little bit more confused.

I can see this working :

var commandProbe = CreateTestProbe("command-probe");
aggregateManager.Tell(command,commandProbe); <--- set probe as  sender
commandProbe.ExpectMsg<SuccessExecutionResult>();

or this :

var result = await aggregateManager.Ask<SuccessExecutionResult>(command); 
// no expect message pattern

but not this

var commandProbe = CreateTestProbe("command-probe");
var result = await aggregateManager.Ask<SuccessExecutionResult>(command); 
commandProbe.ExpectMsg<SuccessExecutionResult>();

[malclear]

It is the second, not the third or your examples (an Ask and an Expect would of course be redundant).
When we are testing for a failed Ask, we use your second example:
var result = await aggregateManager.Ask<FailedExecutionResult>(command); // no expect message pattern

The success responses can still be EXPECTed, but we have to ASK for the failed execution results. In other words, the return of a SuccessExecutionResult seems unchanged, but the return of FailedExecutionResult has begun failing with this release, given that we were using the ExpectMsg pattern. Personally, I suspect it has to do with the usage of params in the Ctor, but that's just a guess.

[Lutando]

You are right, Its serialization seems like it.

[Lutando]

this has been fixed in 0.4.5 :)