(Partially?) addresses
https://github.com/nats-io/nats-server/pull/4349#discussion_r1306576048
@kozlovic @neilalexander I did not remove the use of `domainTk` in the
session subject since it seems to have significance to it; removing it
failed `TestMQTTSessionsDifferentDomains` and I did not understand the
specifics of the issue enough. Please let me know your thoughts.
In +Go 1.20, the `x509.HostnameError` changed to be wrapped in a
[tls.CertificateVerificationError](https://pkg.go.dev/crypto/tls#CertificateVerificationError)
so sometimes the name would not be reset causing tests to be extra
flaky.
In +Go 1.20, the x509.HostnameError changed to be wrapped in a
tls.CertificateVerificationError so sometimes the name would not
be reset causing tests to be extra flaky.
Signed-off-by: Waldemar Quevedo <wally@nats.io>
- [x] Link to issue, e.g. `Resolves #NNN`
- [ ] Documentation added (if applicable)
- [x] Tests added
- [ ] Branch rebased on top of current main (`git pull --rebase origin
main`)
- [ ] Changes squashed to a single commit (described
[here](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
- [ ] Build is green in Travis CI
- [x] You have certified that the contribution is your original work and
that you license the work to the project under the [Apache 2
license](https://github.com/nats-io/nats-server/blob/main/LICENSE)
Resolves#4422
### Changes proposed in this pull request:
- Added `Access-Control-Allow-Origin` header to allow CORS requests for
the monitoring server
- Added a check in the tests for the header when the `Content-Type` is
`application/json`
While shutting down a server an error during purge from a memory stream
would cause a deadlock sometimes, this would sometimes show up in the
`TestJetStreamClusterMemLeaderRestart` while tearing down the cluster.
This was introduced in
4d8d01949b
so only relates to v2.10.
While shutting down a server an error during purge from a memory stream
would cause a deadlock sometimes, this would sometimes show up in the
TestJetStreamClusterMemLeaderRestart while tearing down the cluster.
Signed-off-by: Waldemar Quevedo <wally@nats.io>
When a consumer reached a max delivered condition, we did not properly
synchronize the state such that on a restore or leader switch the ack
pending could jump and be higher than max ack pending and block the
consumer.
This propagates a delivered update and we updated the store state engine
to do the right thing when the condition is reached.
Signed-off-by: Derek Collison <derek@nats.io>
This propagates a delivered update and we updated the store state engine to do the right thing when the condition is reached.
Signed-off-by: Derek Collison <derek@nats.io>
In the new clustering logic for v2.10, sometimes the `TestStressChainedSolicitWorks`
test would flake because a node would end up with only implicit routes. In this change,
we stamp that one of the remotes is configured so that the nodes at least have one explicit
configured remote node.
When moving streams, we could check too soon and be in a gap where the
replica peer has not registered a catchup request but had made contact
via the NRG layer.
This would cause us to think the replica was caught up, incorrectly, and
drop our leadership, which would cancel any catchup requests.
Signed-off-by: Derek Collison <derek@nats.io>
This would cause us to think the replica was caughtup incorrectly and drop our leadership, which would cancel any cacthup requests.
Signed-off-by: Derek Collison <derek@nats.io>
Fix for a bug that would allow old leaders of pull based durables to
delete a consumer from an inactivity threshold timer inadvertently.
Signed-off-by: Derek Collison <derek@nats.io>
We violated the locking pattern, so we now make sure we do this in a
separate Go routine and put checks to only run it once.
Signed-off-by: Derek Collison <derek@nats.io>
