#stepj_api
1 messages ¡ Page 1 of 1 (latest)
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1238481061001039954
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
That does not look like an a Stripe error, where is that coming from?
Hi, here's a full log:
StripeConnectionError: An error occurred with our connection to Stripe. Request was retried 3 times.
| at /Users/stepanjakl/Git/Personal/apostrophe-stripe-products/node_modules/stripe/cjs/RequestSender.js:326:37
| at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
| type: 'StripeConnectionError',
| raw: {
| message: 'An error occurred with our connection to Stripe. Request was retried 3 times.',
| detail: Error: connect ECONNREFUSED 127.0.0.1:12111
| at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) {
| errno: -111,
| code: 'ECONNREFUSED',
| syscall: 'connect',
| address: '127.0.0.1',
| port: 12111
| }
| },
| rawType: undefined,
| code: undefined,
| doc_url: undefined,
| param: undefined,
| detail: Error: connect ECONNREFUSED 127.0.0.1:12111
| at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1606:16) {
| errno: -111,
| code: 'ECONNREFUSED',
| syscall: 'connect',
| address: '127.0.0.1',
| port: 12111
| },
| headers: undefined,
| requestId: undefined,
| statusCode: undefined,
| charge: undefined,
| decline_code: undefined,
| payment_intent: undefined,
| payment_method: undefined,
| payment_method_type: undefined,
| setup_intent: undefined,
| source: undefined
| }
It's a Node.js application
I'm running some Mocha unit tests via a Github workflow action:
name: lint-and-test
run-name: lint and test
on:
push:
branches: ["main"]
pull_request:
branches: ["*"]
jobs:
lint-and-test:
name: Lint and Test
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: 22
- name: Set up MongoDB
uses: supercharge/mongodb-github-action@v1
with:
mongodb-version: 7
- name: Run ESLint
run: npm run eslint
- name: Run Mocha Tests
run: npm run mocha
My best guess is that it is some firewall issue as the connection isn't established, but I have no clue how to get around it.
I have been testing it with act locally: act --container-architecture linux/amd64
Has this ever worked for you?
The tests are passing through fine on my Mac
It sounds like the SDK can't connect to the host you provided but i can't say why that would be happening
https://github.com/stripe/stripe-node?tab=readme-ov-file#initialize-with-config-object
You might need to reach out to github to understand host you can achieve what you're trying to do via actions, i'm not familiar with those
Okay, would you clarify the process and timing for the creation of the Stripe host when configured with a local address?
If its working for you locally, the issue is likely via the host/proxy related to the github action, and I am not familiar with how those work. Ultimately, the SDK needs to be able to connect to Stripe's APi and it seems like the host is not currently connectable. Why are you setting the host to loopback in the first place here, exactly? Are you running a mock API there, for example?
Yes, it's the test API, set up like so:
new Stripe('sk_test_xyz', {
host: '127.0.0.1',
protocol: 'http',
port: 12111,
maxNetworkRetries: 3,
timeout: 10 * 1000
});
What do you mean "the test API" exactly?
Well, I thought if it's set up with a local address, then it's just returning some mock up data, isn't it?
Oh shoot, wait I may need to install the stripe-mock package as well!
Yea none of that behaviour exists by default, that's why i asked about running a mock api