Libelektra: boolean normalization fails

[markus2330]

@kodebach wrote in #2772:

For example today I found this problem. I have no idea, why it didn't come up until now, or why it even is a problem, but here we are:

kdb set -N user /sw/lcdproc/lcdproc/#0/current/lcdproc/foreground true
#> Using name user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> Set string to "true"

kdb get /sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> Sorry, module type issued the error 52:
#> error in the type plugin: The key user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground was already normalized by a different plugin! Please ensure that there is only one plugin active that will normalize this key.

kdb get user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground
#> 1

For context, the type plugin is the only one mounted at this mountpoint that does normalization. It is also not a problem with kdb, since I originally noticed the error with lcdproc itself. So it has to be a problem in kdbGet itself. For some reason it seems type is called twice with the same key.

[markus2330]

@kodebach Are we sure that this is not a cache problem (are you sure that there was no get/ls before the get with the error)? Maybe the origvalue was cached and the type plugin got confused because of this?

[kodebach]

Are we sure that this is not a cache problem (are you sure that there was no get/ls before the get with the error)?

The calls were executed in exactly this order without anything in between. If you call kdb rm user/sw/lcdproc/lcdproc/#0/current/lcdproc/foreground at the end, you can also start the whole thing from the top again.

Maybe the origvalue was cached and the type plugin got confused because of this?

Unlikely, AFAIK if we have a cache hit no plugins are executed.

[markus2330]

Ok, I was thinking about that maybe "origvalue" was cached in unwanted ways. If we can exclude this possibility we would need reproducible steps to debug this problem. It would be a grave bug if the core actually calls your plugin twice without specifying this in infos/placements

[stale[bot]]

I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue.
Thank you for your contributions :sparkling_heart:

[markus2330]

@mpranj can you check if this is related to cache?

[mpranj]

I don't think this is cache related, but I would not rule it out completely. I tested it with the cache (and mmapstorage) not compiled at all vs with cache enabled. I get the same result each time and can not reproduce this problem.

Here is the test case I used, can you give a hint if something is wrong in the test case?

kdb mount typetest.ecf user/tests/type dump type

kdb set -N user /tests/type/thing true
#> Using name user/tests/type/thing
#> Create a new key user/tests/type/thing with string "true"

kdb meta-set user/tests/type/thing type boolean

kdb get /tests/type/thing
#> 1
kdb get user/tests/type/thing
#> 1

[markus2330]

@kodebach can you complete the original test case (top post)? Without the config in /sw/lcdproc/lcdproc/#0 it cannot be reproduced.

[kodebach]

This may very well have been fixed already. I will however try to reproduce it without the LDCproc spec.

If I remember correctly, the origvalue meta-key was persisted (not in the cache but in the actual mounted config file). This then appears to the type plugin, as if some other plugin has incorrectly normalized the key.

EDIT: I will close the issue for now and reopen it, if I can reproduce the issue.