Once a monitor command is sent, the connection will stay open and stream all commands handled by the server. This works both via redis-cli as well as telnet. Meaning, a SIGINT (CTRL-C) sent from the redis-cli or a "quit" command sent over telnet will both stop monitoring gracefully.
MULTI commands are handled appropriately as well, meaning a "multi" command will be logged immediately, but queued commands will only log after "exec" is sent ("exec" is logged last in the monitor output).
Internals
I made one change to how the handler chain works. Instead of pure functions, I added a handlers type in order to share monitoring subscriptions across the handler chain (it's how I ensure that "multi" and related commands get logged appropriately).
I also added a monitors type which represents a set of connections that subscribe to command request logs. Connections run in a detached state so it handles reading, flushing, and closing. It also manages the subscription pool to fan out monitor logs appropriately.
Testing
There are two monitor tests: One which verifies that starting and stoping the monitor command work as expected. And one which verifies that commands from other clients are written out as expected.
Fixes https://github.com/nalgeon/redka/issues/23 by adding the "monitor" command.
Compatibility
Behavior should be near-identical to what's documented here: https://redis.io/docs/latest/commands/monitor/
Once a monitor command is sent, the connection will stay open and stream all commands handled by the server. This works both via redis-cli as well as telnet. Meaning, a SIGINT (CTRL-C) sent from the redis-cli or a "quit" command sent over telnet will both stop monitoring gracefully.
MULTI commands are handled appropriately as well, meaning a "multi" command will be logged immediately, but queued commands will only log after "exec" is sent ("exec" is logged last in the monitor output).
Internals
I made one change to how the handler chain works. Instead of pure functions, I added a
handlers
type in order to share monitoring subscriptions across the handler chain (it's how I ensure that "multi" and related commands get logged appropriately).I also added a
monitors
type which represents a set of connections that subscribe to command request logs. Connections run in a detached state so it handles reading, flushing, and closing. It also manages the subscription pool to fan out monitor logs appropriately.Testing
There are two monitor tests: One which verifies that starting and stoping the monitor command work as expected. And one which verifies that commands from other clients are written out as expected.
I haven't performed any benchmarks.
Happy to take feedback or make changes :)