The documented way of loading functions to allow calling them is not correct. The docs at this location: https://docs.puppetlabs.com/guides/custom_functions.html#calling-functions-from-functions says that the function "loadall" should be called. That is neither recommended nor required. The function can simply be called (as already documented), or loaded by name (also as documented).
The reported problem can be fixed by specifying the environment from which the function should be loaded in the call to loadall. This is however already
correctly done by the direct call using the function_ prefix, as well as and the load of a single function. The load is useful if the user wants to check
if the function is available (to give a custom error message).
Using loadall is not recommended (even when given an environment), since it loads all functions - which is both slow and makes unused functions take up memory. User code should not really interact directly with the autoloaders. Suggest skipping mentioning loadall in the documentation.
According to puppet custom function documentation, if one wanted to call a custom function from within another custom function, `Puppet::Parser::Functions.autoloader.loadall()` is required first. While creating a function library I noticed that older versions of my functions were being run even when restarting my master server. Upon further digging and running puppet from source, I found a few things:
1. It appears that in lib/puppet/util/autoload.rb, line 131 (acd5fd0 Merge branch 'PUP-2478/3.6.1/security_fixes' into stable) `env` is not getting set to the current_environment.
2. A good workaround for me is to use `Puppet::Parser::Functions.autoloader.load(:function)`, although this may result in loading functions more times than necessary.
3. In later releases, another suitable workaround might be to call `Puppet::Parser::Functions.autoloader.loadall(Puppet.lookup(:current_environment))` instead.
4. Modifying the source of line 131 to load the current env also fixed my issue, so you may want to investigate that as a possible upstream solution.
It looks like this bug has been there for some time, so I must be exercising an usual use case if I'm the first to hit it. Or maybe there is something else I'm missing. Please let me know. Thanks.