Error: backup-all-forms is failing when I try to upload a config

[tatilepizs]

Describe the bug
When I try to upload a config, using the command cht --local it fails consistently when it tries to perform the action backup-all-forms it fails with the error:

INFO Starting action: backup-all-forms…
INFO FetchError: request to http://localhost:5988/medic/form%3Atreatment_followup_under_5/model.xml?rev=2-429264c96a85e95e881b0e68b8e755df failed, reason: connect ECONNRESET 127.0.0.1:5988
    at ClientRequest.<anonymous> (/usr/local/Cellar/node@16/16.20.1_1/lib/node_modules/cht-conf/node_modules/pouchdb-fetch/node_modules/node-fetch/lib/index.js:1491:11)
    at ClientRequest.emit (node:events:513:28)
    at Socket.socketErrorListener (node:_http_client:494:9)
    at Socket.emit (node:events:513:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
ERROR request to http://localhost:5988/medic/form%3Atreatment_followup_under_5/model.xml?rev=2-429264c96a85e95e881b0e68b8e755df failed, reason: connect ECONNRESET 127.0.0.1:5988

But, if I execute only the action backup-all-forms sometimes it passes and sometimes it fails.

Expected behavior
The config should be uploaded without any problem. It is working fine for other people using linux for example.

Environment

• node: v16.20.1
• cht-conf: INFO 3.20.0
• cht-core: ~4.5.0
• OS: macOS Sonoma version 14.1.1, intel

[mrjones-plip]

@garethbowen - this was run against CHT Core on master @ ~4.5.0 - any chance that the new rate limiting could have caused the connect ECONNRESET? I don't THINK so, but figured it'd be worth double checking!

[garethbowen]

@mrjones-plip Great thinking! Some things to look at...

1. Unless there's a bug the rate limiting should only kick in if you give incorrect credentials. Check that they're right, but I'd expect cht-conf to fail on the first request with some sort of login error.
2. Check the API log for a 429 (only returned from the rate limiting code)

My best guess for this error is API is crashing. Check the API log for an uncaught exception that would cause it to stop in a hurry...

[mrjones-plip]

ah - gotcha! This was endemic to @tatilepizs's laptop, so we'll have to wait until her return next week to check for API crash (or API 429). Stay tuned!