Redis 3.2.9 preserves the configured Lua time limit

A configuration file can parse successfully while later initialization silently replaces one of its values. Redis 3.2.9 corrects that ordering for lua-time-limit. The change moves the default assignment into server-configuration initialization, so initializing the scripting subsystem no longer overwrites what the user configured.

The 3.2 release notes date the maintenance release to 17 May. The versioned notes classify its urgency as low and describe the corrected bugs as rarely harmful. That classification distinguishes this update from the security and allocator issues addressed by the preceding releases, while leaving several useful operational corrections to explain.

I like Redis's relatively direct configuration model. A setting's usefulness nevertheless depends on when the implementation applies it. This patch fixes the relationship between the supplied value and the default, rather than adding another tuning option.

Defaults belong before user configuration

The Lua-limit patch removes the assignment to server.lua_time_limit from scriptingInit. It adds the same assignment to initServerConfig. The commit message says the old placement overwrote whatever the user set.

The default value itself is not the subject of the fix. The shipped configuration still gives a limit of 5,000 milliseconds. An installation selecting that value may not notice the ordering problem because the later default assignment agrees with its intended setting.

The defect becomes meaningful when an operator chooses a different value. A successful parse would suggest that the choice had taken effect, while the later scripting initialization could restore the default. Correcting the initialization order makes the explicit setting survive into the subsystem that uses it.

The supplied example retains this directive:

lua-time-limit 5000

That value must also be interpreted according to the documented behavior. The setting does not promise to roll back and terminate every script after five seconds. When a script exceeds the limit, Redis logs the condition and starts returning errors to queries while the script remains in execution.

The configuration comments identify SCRIPT KILL for stopping a script that has not yet issued write commands. If the script has already written and the operator does not want to wait for natural termination, they identify SHUTDOWN NOSAVE as the shutdown path. Setting the limit to zero or a negative value permits unlimited execution without the warnings. Preserving a chosen limit matters because it affects when the server enters this documented long-running-script behavior.

Diagnostic tools should retain the server's error

Another patch in the release changes error reporting in redis-cli --bigkeys. The tool asks Redis for each key's type. Previously, a reply outside the expected status-reply category produced an invalid-reply-type message, even when the server had supplied a meaningful error string.

The corrected branch checks specifically for REDIS_REPLY_ERROR and prints the server's error text. Unexpected reply categories still get the generic diagnostic. Both cases exit with failure, so the change improves the explanation of failure without converting it into success.

This distinction helps an operator locate the failed layer. A server error is an actual response with content. Reporting only its numeric reply category removes information that may explain why the request failed. The CLI now preserves that information where the reply contains it.

I find such changes useful in maintenance releases because diagnostic tools often become relevant when the service already needs attention. An accurate error does not correct the underlying condition, but it prevents the tool from discarding evidence the server has already provided.

Error exits release their descriptors

The release also includes replication cleanup. In syncWithMaster, the patch initializes a descriptor variable to -1 and closes it on the error path if it holds an open descriptor. The sentinel value distinguishes resources that were acquired from resources the function never opened.

The error path already removed event-loop handlers and closed the connection descriptor. The additional close covers another descriptor owned during synchronization. Cleanup has to account for both resources, even though the function is leaving through one shared error label.

A separate AOF patch closes pipes when a background append-only-file rewrite fails to fork. It adds aofClosePipes() before returning the error. This addresses resources allocated for work that could not start, rather than the normal completion of a rewrite child.

These corrections affect uncommon paths without changing the meaning of normal commands. The Lua setting survives subsystem initialization, the CLI retains a returned error message, and failed background or synchronization work releases the descriptors it acquired. Redis 3.2.9's low urgency describes the maintainers' assessment of the failures, while the individual patches identify exactly which configuration and failure paths change.