invalid jetstream publish response

[yeqown]

Observed behavior

if _, err = p.js.PublishMsg(msg); err != nil {
return err
}

then it returns the above error, I found this error message from nats.go and found it was defined as ErrInvalidJSAck, and used here:

These two code blocks return the error but without the root cause, it's uncertain while locating the error, what's worse the error is not stable enough to reproduce locally.

I'm using the remote nats-server to eliminate differences, the client is using the same code to reproduce, but it's not reproduced yet.

Expected behavior

I wonder dose this error will take any effect. Can I ignore this error directly, if not what could I do to locate the error cause and fix it?

Server and client version

server = 2.10.5
client = 1.28.0 / 1.27.1

Host environment

No response

Steps to reproduce

I could not reproduce it on my local yet

[Jarema]

Thanks for filling the issue!

While it's always nice to know what caused this error, I don't think its necessary to improve the error handling and wrapping the Unmarshal error.

Are you interested in contribution here?

[yeqown]

Thanks for filling the issue!

While it's always nice to know what caused this error, I don't think its necessary to improve the error handling and wrapping the Unmarshal error.

Are you interested in contribution here?

Thanks for replying.

I do not mean to wrap error here, I just wonder what caused this error. Actually, I want to figure out why, and any information to resolve this error. Now, It happens so frequently in my code.

Of course, I'd love to contribute here if it's really necessary.

[yeqown]

@Jarema I log the detail of the ackResp and got this, the ErrInvalidJsAck raised here because of the empty resp.Data

Can you help me to analyze this deeply?

all changes here, checkout from v1.31: main...yeqown:nats.go:feat/debug

I alse tried to subscribe the _INBOX. directly and then I got:

Does it mean the client received a duplicated ack from the server side?

[piotrpio]

Doubled response from the server definitely looks suspicious. Could you give us some more details so we may try and reproduce? It would be nice to have:

• debug/trace server logs from when the publish and duplicated ack happen
• stream config (mainly around policies)
• are you using plain js.Publish() or do you use any additional options?

[yeqown]

Doubled response from the server definitely looks suspicious. Could you give us some more details so we may try and reproduce? It would be nice to have:

• debug/trace server logs from when the publish and duplicated ack happen
• stream config (mainly around policies)
• are you using plain js.Publish() or do you use any additional options?

@piotrpio

1. logs with inbox filtered
   

The server dose send 2 messages into inbox to cids(371 and 1423), and the first has 0 size, and the second is actually expected.

2. Output of nats str info:

Information for Stream local_account created 2023-09-11 18:22:57

              Subjects: local_account.>
              Replicas: 1
               Storage: File

Options:

             Retention: Limits
       Acknowledgments: true
        Discard Policy: Old
      Duplicate Window: 2m0s
     Allows Msg Delete: true
          Allows Purge: true
        Allows Rollups: false

Limits:

      Maximum Messages: unlimited
   Maximum Per Subject: unlimited
         Maximum Bytes: unlimited
           Maximum Age: unlimited
  Maximum Message Size: unlimited
     Maximum Consumers: unlimited

State:

              Messages: 84,468
                 Bytes: 28 MiB
        First Sequence: 1 @ 2023-09-12 14:57:25 UTC
         Last Sequence: 84,468 @ 2024-01-09 09:28:46 UTC
      Active Consumers: 37
    Number of Subjects: 8

3. yes, it's pure
   
   

[yeqown]

😂😂😂 I thought I have figured out:

The message published was Respond at another subscribing client. It called msg.Respond

// Respond allows a convenient way to respond to requests in service based subscriptions.
func (m *Msg) Respond(data []byte) error {
	if m == nil || m.Sub == nil {
		return ErrMsgNotBound
	}
	if m.Reply == "" {
		return ErrMsgNoReply
	}
	m.Sub.mu.Lock()
	nc := m.Sub.conn
	m.Sub.mu.Unlock()
	// No need to check the connection here since the call to publish will do all the checking.
	return nc.Publish(m.Reply, data)
}

[yeqown]

@Jarema I have make a PR to wrapping JS publish error, would you mind to push it going on 👏?