-
-
Notifications
You must be signed in to change notification settings - Fork 248
Upgrade NATS library used for tests #1009
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
✅ Deploy Preview for testcontainers-node ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
This will have to be a breaking change because of the change to the default image. |
joebowbeer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requested change: The new dependencies should be devDependencies
| (async () => { | ||
| for await (const m of sub) { | ||
| const actual: string = sc.decode(m.data); | ||
| const actual: string = m.string(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, Base64Codec static functions are provided by @nats-io/obj
Base64Codec.encode()
Base64Codec.decode()There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NATS examples in their own documentation are out of date, but I found test cases which use string(), so I picked those. I do not think this PR should deviate to use the suggested Base64Codec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think toString is a suitable transport encoding to use even in an example.
| private values = new Map<string, string | undefined>(); | ||
|
|
||
| constructor(image = "nats:2.8.4-alpine") { | ||
| constructor(image = "nats:2.11.3-alpine") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cristianrgreco I noticed that the other NATS Testcontainers (Go, .NET, Python) are defaulting to a scratch image (nats:2.9) which is actually smaller than the alpine image.
More importantly, the two images are not interchangeable. This Testcontainer's code requires the alpine base image, as explained below.
The standard image's Dockerfile provides nats-server in its ENTRYPOINT whereas the alpine Dockerfile combines nats-server with the rest of CMD. As a result, if the NodeJS user specifies NatsContainer("nats:2.11") instead of NatsContainer() or NatsContainer("nats:alpine") then the container will crash.
Would you be open to switching to the standard scratch nats image here, for consistency with other implementations?
Actually, I think best of both worlds can be achieved by simply omitting "nats-server" here:
| const result: string[] = ["nats-server"]; |
Then the alpine entry point script below will add it, and then this Testcontainer will also work if the scratch "nats" image is used instead of alpine:
In other words, I think the default image can still be alpine and this Testcontainer can also be compatible with the scratch images.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joebowbeer Nice observation! Sounds good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joebowbeer Can that be done in a separate pull request? I need a working NATS testcontainer to be unblocked. An optimal NATS testcontainer would be a future goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdinsel-xealth I agree it can be done in a separate PR. What I don't understand is, this PR is now only changing a dev dependency used only by this repository's tests, and updating a test. What part of this is blocking you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See issue #1008. While using the example provided for this testcontainer, there was an unknown exception caught in the connect operation which returned a connection refused message, but this was crafted by the NATS code. The root cause is not fully known.
console.log
testcontainers:containers [949c57f40de8] [1] 2025/05/22 19:11:45.548358 [INF] Server is ready +1ms
at Logger.debug [as logger] (../node_modules/debug/src/common.js:113:10)
console.log
socket error AggregateError:
at internalConnectMultiple (node:net:1139:18)
at afterConnectMultiple (node:net:1714:7)
at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
code: 'ECONNREFUSED',
[errors]: [
Error: connect ECONNREFUSED ::1:33412
at createConnectionError (node:net:1677:14)
at afterConnectMultiple (node:net:1707:16)
at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -61,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 33412
},
Error: connect ECONNREFUSED 127.0.0.1:33412
at createConnectionError (node:net:1677:14)
at afterConnectMultiple (node:net:1707:16)
at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -61,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 33412
}
]
}
at Socket.<anonymous> (../node_modules/@nats-io/transport-node/src/node_transport.ts:128:7)
console.log
socket close
at Socket.<anonymous> (../node_modules/@nats-io/transport-node/src/node_transport.ts:132:15)
console.error
Error connecting to NATS: ConnectionError: connection refused
at NodeTransport.connect (/Users/jeremy.dinsel/git/xealth-patient-engagement-service/node_modules/@nats-io/transport-node/src/node_transport.ts:113:11)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
at ProtocolHandler.dial (/Users/jeremy.dinsel/git/xealth-patient-engagement-service/node_modules/@nats-io/nats-core/build/src/protocol.ts:552:7)
at ProtocolHandler._doDial (/Users/jeremy.dinsel/git/xealth-patient-engagement-service/node_modules/@nats-io/nats-core/build/src/protocol.ts:600:9)
at ProtocolHandler.dodialLoop (/Users/jeremy.dinsel/git/xealth-patient-engagement-service/node_modules/@nats-io/nats-core/build/src/protocol.ts:652:11) {
[cause]: AggregateError:
at internalConnectMultiple (node:net:1139:18)
at afterConnectMultiple (node:net:1714:7)
at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
code: 'ECONNREFUSED',
[errors]: [ [Error], [Error] ]
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume then you're having the same error after the changes made in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't explain the differences in the repositories. I've even created a separate repository with only vitest, @testcontainers/nats, and the two @nats-io dependencies. The only code in the repository is the example test from this repository for NATS. It fails with the same errors I've reported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right.. well I've no idea how this PR relates to #1008, but I guess thanks for updating the library used for our NATS tests! LMK if you're planning on making any additional changes, else LGTM.
@joebowbeer A separate PR with what you proposed would be great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the .devcontainer from this repository to my test repository and the connection with NATS succeeds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a solution with some combination of information from https://node.testcontainers.org/supported-container-runtimes/#usage_2. I'll post the details in the related issue. Please decide if you want to keep this PR or close it.
What would the timeline be? I'll revert the default container version as tests pass with it using either version. |
joebowbeer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I can add-back the (Base64)Codec in a subsequent PR
|
@cristianrgreco @jdinsel-xealth PR to add a codec to the "pubsub" sample code and add compatibility with the "nats" scratch images: |
Story
NATS support was broken with a newer version of NATS. An issue was opened describing the situation #1008
This pull request upgrades the NATS components and uses their migration guide to modify the code to support it.