[RaphaelFakhri]

ParseMemcached reads the key of set, add, delete, incr, and similar commands by cutting the payload at the first space after the key. The standard delete <key>\r\n command has nothing after the key, so the parser returned an empty command. Trace.MemcachedQuery then skipped the span, so memcached delete calls never showed up in traces, even though the eBPF filter (is_memcached_query) captures them.

This change falls back to the end of the line when no space follows the key.

Testing

• Added delete 1111\r\n and delete 1111 noreply\r\n cases to Test_parseMemcached.
• go test ./ebpftracer/l7/ passes. Without the fix, the new delete 1111\r\n case fails with expected: "delete", actual: "".
• gofmt, goimports, and go vet report no issues for the package.

[def]

@RaphaelFakhri just curious, how does knowing the key help you personally? What use case do you have for seeing the actual Memcached key in traces?

[RaphaelFakhri]

@def I found this while reading the Memcached parser, not from a deployment of my own. The effect is wider than the key: for delete <key>\r\n, the most common form of delete, ParseMemcached returns an empty command as well, so those calls show up without a command name in traces. With the fix they show as delete with their key, the same as set and incr already do.

[def]

If there are no practical reasons for this change, I'll close this PR.