Panic on PullSubscribe with missing permission

[guyguy333]

Defect

Make sure that these boxes are checked before submitting your issue -- thank you!

• [x] Included nats.go version
• [ ] Included a [Minimal, Complete, and Verifiable example] (https://stackoverflow.com/help/mcve)

Versions of nats.go and the nats-server if one was involved:

• nats.go: 1.25
• nats-server: 2.9.0

OS/Container environment:

Docker

Steps or code to reproduce the issue:

PullSubscribe with missing permission produces this error on NATS side Publish Violation - User "xxxxx", Subject "$JS.API.STREAM.PURGE.xxxxxx" but a crash on NATS Go client. Adding the missing permission solves the issue

Expected result:

Proper missing permission error and not a panic.

Actual result:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1a0 pc=0x9dfee7]

goroutine 37219 [running]:
github.com/nats-io/nats%2ego.(*js).subscribe(0xc00051c420 - , {0xc0750b4600, 0x5b}, {0x0, 0x0}, 0x0, 0xc0750a8480, 0x1, 0x1, {0xc0750c4040, ...})
	/go/pkg/mod/github.com/nats-io/[email protected]/js.go:1721 +0x12c7
github.com/nats-io/nats%2ego.(*js).PullSubscribe(0xc00051c420, {0xc0750b4600, 0x5b}, {0x0, 0x0}, {0xc0750c4040, 0x2, 0x2})
	/go/pkg/mod/github.com/nats-io/[email protected]/js.go:1289 +0x17a

[piotrpio]

Hello @guyguy333 , thanks for creating the issue. I'm trying to replicate the problem and I'm having some issues, I hope you'll be able to clarify it for me:

• You're saying that the server error is Publish Violation - User "xxxxx", Subject "$JS.API.STREAM.PURGE.xxxxxx" - I assume that this is not the error seen when creating the subscription? Calling PullSubscribe() does not purge the stream, so that seems to be fired elsewhere.
• Ideally, could you prepare a small example (e.g. a test) which is failing as you described? I tried to create a pull subscription without permissions and I properly get a timeout and asynchronous "Permissions Violation" callback.

Thanks

[enzalito]

I think that the problem simply comes from the fact that after info, err := js.upsertConsumer(stream, cfg.Durable, ccreq.Config) on js.go:1663 there is a clause that is entered if err != nil, this clause de-references info which will be always be nil

[piotrpio]

@TonDar0n , thanks for digging into it, but I'm not sure that's the issue. The panic happens in js.go:1721, that's in else (so only if err == nil). The only possibility of info being nil at that pont would be if js.upsertConsumer() returned nil, nil, which I don't think it does. So I would assume sub.jsi is nil, but could not pinpoint the problem without any example.

[enzalito]

You're right, I read the code too quickly my bad ! But if s.jsi is nil wouldn't the code panic on js.go:1720 ? There might be a case were js.upsertConsumer returns err == nil and info == nil. It could also be a concurrency problem but as far as I can see s.jsi seems properly write protected.

[evanofslack]

@piotrpio @wallyqs Bumping this, has there been any more updates on this?

I've seen this issue after pull subscribing with non unique filtered consumer. We would expect this to just return an error but not panic.

client: 1.24.0 server: 2.9.15

err=nats: filtered consumer not unique on workqueue stream
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1a0 pc=0xdcc48f]

goroutine 14161 [running]:
github.com/nats-io/nats%2ego.(*js).subscribe(0xc0011c2960, {0xc0005ec0a0, 0x4c}, {0x0, 0x0}, 0x0, 0xc0011c2e40, 0x1, 0x1, {0xc00105dc00, ...})
	/home/users/eslack/go/pkg/mod/github.com/nats-io/[email protected]/js.go:1719 +0x126f
github.com/nats-io/nats%2ego.(*js).PullSubscribe(0xc0011c2960, {0xc0005ec0a0, 0x4c}, {0xc000c384e0, 0x58}, {0xc00119e1e0, 0x1, 0x1})
	/home/users/eslack/go/pkg/mod/github.com/nats-io/[email protected]/js.go:1289 +0x18a

[piotrpio]

@evanofslack are you able to reproduce this? If so, could you provide an example?

[evanofslack]

@piotrpio I have not been able to reproduce this despite trying. It just happened one time in a test environment. Sorry, not much to go off.