NATS subjects are dot-separated tokens. JetStream's KV store layers on top of that and validates keys through keyValid in kv.go and searchKeyValid in jetstream/kv.go. Both reject keys with a leading or trailing dot.
What they didn't reject was keys with consecutive dots in the middle. foo..bar has an empty token, which makes it an invalid NATS subject. The server bounces it, but by that point you're already on the wire, and the error coming back is the misleading nats: jetstream not enabled rather than something like invalid key.
So this was really a UX bug. Two adjacent dots passed client validation, hit the server, and the server's error didn't tell you what was actually wrong.
Fix is a one-liner in both validators:
if strings.Contains(key, "..") {
return false
}Added Watch("foo..bar") and Watch("test..") to the existing invalid watchers subtest in jetstream/test/kv_test.go. Both return ErrInvalidKey now before any network call.
The kind of bug where the original author was clearly thinking about subjects ending in a dot (an empty last token) but missed that the same problem applies anywhere a token is empty. Easy to miss, satisfying to find.