#10004 introduce Redis function libraries which allows code sharing between functions by uploading a batch of functions together. We open this issue to discuss functions flags that was left open on #10004.

Library Functions Flags

The orginal suggestion on #9906 was to support flags that can be given to Redis when the library creates a function. Those flags are used to tell Redis when it is OK to invoke the function. For example, one flag might indicate to disallow running the function if Redis reached its memory limit. Here is the list of flags we plan to support first (other flags might be added in the future):

• DENY_OOM - do not allow the function to be invoked if the memory limit is reached.
• BREAK_ATOMICITY - indicate that it's OK to kill the function even if it already performed a write command or disallow write * commands if OOM reached.
• NO_REPLICATE - indicate that all the data created by the function is temporary and should not be replicated to replicas/aof. Equivalent to redis.set_repl.

Note: DENY_OOM can solve this issue: #8478

A discussion with @oranagra raised concerns and open question about this topic and we would like to community input to decide how to proceed.

How to handle unknown flags

Assume on Redis 7.2 we will add a new flag that was not exists on Redis 7.0, how should Redis 7.0 handles this flag. One approach is to decide from day one that flags are just a hints and if Redis do not recognise them then it just ignores. The advantage is that script could then run on Redis 7.2 and Redis 7.0 without any change. The disadvantage is that user might expect some functionality but he will not get it on Redis 7.0. Also we will get different behaviour between Redis 7.0 and Redis 7.2 on the same script. To illustrate it, take for example the DENY_OOM flag describe above, assuming we will only support it on Redis 7.2. If user will use it he will not be able to execute the function if OOM reached but he will be able to execute it on Redis 7.0 (even if OOM reached).

The alternative is to raise an error if we see a flag which is not recognised. The advantage is that everything is explicit, if something is not supported the user will get an error and can decide how to handle it. The disadvantage is that we pass more responsibility and complexity to the user. Important thing to notice is that such complexity exists even today, if a user uses redis.set_resp API he needs to consider the case in which this API do not exists in order to be compatible with old Redis versions.

Personally I prefer option 2 but would like to hear others opinions.

Lua API

How do we expose the ability to set flags with the Lua API. #10004 introduce the following API to register a function: redis.register_function(<function_name>, <callback>, [<description>]). It is possible to add another argument to pass the flags, but then every time the user want to pass a flag he must also pass a description because both are positional arguments.

Another option is to allow a version of redis.register_function that gets a named arguments:

redis.register_function {
    name='f1',
    callback = function() return 1 end,
    description = 'some desc',
    flags = ...
}

If we decide to add this named argument version we should do it before Redis 7.0 to prevent another backward compatibility issue for functions (a script that will use the named argument API will not work on Redis 7.0)