If you’re a programmer you’ve likely heard or read someone expound the benefits and advantages of typed code. Things like compile-time validation that you are passing an integer rather than a string, or avoiding variable type overloading, speed, and many more. However, sometimes this can lead to better code in programs other than the one you’re writing in a statically typed language.
The Background: Redis Info Command Results
When interacting with a Redis instance, you can get quite a bit of information
about it using the
info command, complete with several sections such memory,
server, and stats. Basically Redis returns a big multi-line string with the
information. For example the memory section response looks like this:
# Memory used_memory:1007440 used_memory_human:983.83K used_memory_rss:1826816 used_memory_rss_human:1.74M used_memory_peak:1007440 used_memory_peak_human:983.83K total_system_memory:8589934592 total_system_memory_human:8.00G used_memory_lua:37888 used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:1.81 mem_allocator:libc lazyfree_pending_objects:0
If you run
info all or don’t specify a section you get multiple stanzas like
the above, one for each info section.
Updating Libredis,The Typed Go Client Library
Nearly all client libraries for Redis return this as a big string. If you want to know how much memory is available before Redis starts refusing more additions, you have to parse that out yourself. I’m not a fan of making the client library user do all of the parsing. So when I forked GoRedis and made “libredis”, one of the reasons was to enable the info call to return a typed structure.
Each info section is a Go
struct, and when parsing the entire output these
structs are members of a master struct. Each item, such as “maxmemory” is
parsed into the appropriate type; in the case of maxmemory that being an
int64. In some cases the values are themselves nested data and need to be
parsed even further.
Now to be certain this meant a fair bit more work for me. I had to code up the parsing and conversion of all existing fields and values in the info command’s various sections. Fortunately Go makes this relatively easy. However, it also means that whenever Salvatore adds new fields I have to add them as well or they go unused. While this has not happened often, and the existing code simply ignores new stuff it doesn’t recognize, it has happened a few times, most recently today.
Today, while playing around with ObjectRocket’s 3.2 release candidate offering,
I noticed several new fields as of 3.2. I knew one of them,
total_system_memory, was coming. However I hadn’t realized maxmemory was going
to be there, let alone
maxmemory_policy. So off to add them I went. And when I
did, I ran into a bit of a problem. The
maxmemory_policy was listed as unknown.
I thought, “now why is that?”. So I turned to the source code.
I discovered that Redis uses an
enum internally to record the eviction
policy, which is the same as
maxmemory_policy, and uses a function to convert
said enum’s value to the string. If it doesn’t find a string matching the
enum’s value it returns unknown. With a bit more digging I found that it was
actually passing to this function the current maxmemory value, rather than the
policy enum value. Since maxmemory was (much) larger than the enum the value
wasn’t found, “unknown” was returned. Thus, as of this writing, if you run a
stock configured Redis 3.2 (or git unstable) version it will report
‘volatile-lru” as the default maxmemory is zero, and the first item in the enum
is “volatile-lru”. If you set it to any useful maxmemory limit it will be
With a bit of work I had a pull request ready to go to fix this. For more issue details, and the pull request, you can see Issue 3187. Hopefully this fix will hit 3.2 prior to it being marked stable.
Hurray For Static Typing On The Client
Because I, as a client library author choosing to define and use a static typed structure to parse out the info responses, had to go I an manually add these changes I was forced to confront the response given, find it was incorrect, and fix it. Had I taken the route of simply using one of the other Go Redis libraries, or taken the “let the use parse it” route, I’d not have noticed this change and thus not have fixed it.
Even were I not inclined to dig into the source code reporting it as a bug would still have led Salvatore (or another contributor) to fix it and Redis still would have been improved. Even though Redis is written in a statically typed language, the fact that it merely output strings for this command, regardless of actual data types, provided an “escape route” for that code path. With something on the other side checking it by being statically typed as well, it closed this escape route.
One could make the case this is a (another?) good reason why, at least with out-of-process services, your testing code should validate everything and arguably be in a different language. Perhaps forcing type conversions in your consumers would be a useful core service test addition to many language. Just make sure you aren’t using a shared library which could mean sharing a non-validation bug in the test as well. Yes, it is more work, but isn’t the effort for testing just as important as the effort for developing the code in the first place?