Panic with control feature enabled and conditional lamdas

[dee0sap]

Running
spiff++ --features control merge i.yaml
with the file below yields a panic
panic: interface conversion: interface {} is dynaml.LambdaValue, not map[string]yaml.Node

However I am expecting ... unknown function 'getCredentials'

Sidenote... what I am wanting to do is make it possible to test the spiff files I am using in my OCM toi installer without requiring that I build a component and run the toi installer through OCM. To do that I need to somehow 'inject' a mock/lambda implementation of getCredentials.

So what I would really appreciate is anything that streamlines that.

# i.yaml 
foo: bar

getCredentialsWrapper:
  <<if: (( defined(stub(getCredentials)) ))
  <<then: (( lambda |x,y|->stub(getCredentials)(x,y) ))
  <<else: (( lambda |x,y|->getCredentials(x,y) ))

user: (( .getCredentialsWrapper.blah( "myExecutorOCI", "user" ) ))

[mandelsoft]

Hi @dee0sap,

I think the .blah is not expected and it should be .getCredentials (because this is no builtin function), but anyway I can reproduce the panic.

Here is a short workaround without the control feature:

getCredentialsWrapper: ((  defined(stub(getCredentials)) ? lambda |x,y|->stub(getCredentials)(x,y) :lambda |x,y|->.getCredentials(x,y) ))

user: (( .getCredentialsWrapper( "myExecutorOCI", "user" ) ))

getCredentials: (( |x,y|->x "," y ))

I'll try to fix this panic, but it requires some more investigation.

[mandelsoft]

Ok, the reason is tricky, I tried a quick fix, hoping it has no other consequences.
Fix is in branch dev.

working version should be:

getCredentialsWrapper:
  <<if: (( defined(stub(getCredentials)) ))
  <<then: (( lambda |x,y|->stub(getCredentials)(x,y) ))
  <<else: (( lambda |x,y|->.getCredentials(x,y) ))

user: (( .getCredentialsWrapper( "myExecutorOCI", "user" ) ))


getCredentials: (( |x,y|->x "," y ))

but I think the version with the conditional operator above should be better.

[dee0sap]

Thanks @mandelsoft !

I did end up switching to the conditional operator as it doesn't have a problem.

I avoided it at first due to the number of devs out there, for reasons I cannot fathom, that claim the traditional ternary operator is hard to read.