How do I identify cause of Axios "Network Error"? - reactjs

Question

I can't get an Axios "get" request working for a front-end/back-end pair after moving the code from CentOS 7 to a CentOS 8 instance. The code in question works just fine on a different AWS EC2 instance. I can't make it work on the new EC2 instance running Rocky Linux v8.5.
When I catch the exception to look at the error, I see a most unhelpful:
Error: Network Error
I can find NO information about the complaint was or how to fix it. I can't get ANY useful information about what is causing the issue. I'm sure it's something stupid and easy to fix -- it would be much easier if I can somehow get the technology stack to tell me what the issue is.
I use the axios component to access a Node Express service running on the same instance that hosts the React app. The service is listening to https on port 7003. The React app calls this server, and returns data provided by the service.
I use axios for all communication between the React app and the rest of the world, so I need to fix this.
I use VisualStudio Code (VSC) to develop my React and NodeJS code.
When I exercise the service using wget, it seems to work:
$ wget "https://my.domain.name.com:7003/getEnvironment"
--2022-02-24 21:46:46-- https://my.domain.name.com:7003/getEnvironment
Resolving my.domain.name.com (my.domain.name.com)... 172.30.2.147
Connecting to my.domain.name.com (my.domain.name.com)|172.30.2.147|:7003... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11205 (11K) [application/json]
Saving to: ‘getEnvironment’
getEnvironment 100%[===================================>] 10.94K --.-KB/s in 0s
2022-02-24 21:46:46 (220 MB/s) - ‘getEnvironment’ saved [11205/11205]
I notice that wget says it's using "HTTP" even though I've given it "https" in the command-line.
I run the front-end in VSC using the React/VSC development server. That server listens on port 3003.
I've turned on cors for the service, and it is listening on port 7003 as expected. That's why the wget works.
The back-end (service) code looks something like this:
...
var cors = require('cors');
...
var app = express();
...
app.use(cors({origin: true, credentials: true}));
...
The front-end code that is failing looks like this:
checkStatus(response) {
if (response.status >= 200 && response.status < 300) {
return response.data;
} else {
const error = new Error(`HTTP Error ${response.statusText}`);
error.status = response.statusText;
error.response = response;
console.log(error);
throw error;
}
}
privateLoadEnvironmentUsingURL(url) {
return axios
.get(url)
.then((response) => {return this.checkStatus(response)})
.catch((error) => {
console.log(error);
throw error;
});
}
I've exercised this with both front-end and service in VSC. The axios call is failing and so far as I can tell is doing so before ever invoking the service.
It takes awhile to fail, leading me to suspect a timeout is in play. I see no indication in the nodejs service code that the request is actually hitting the service.
It therefore appears that the "preflight" negotiation is blocking this call. Turning on cors is pretty much all I know how to do -- I don't have deep insight into cors.
I've been waving voodoo chickens at this code all afternoon to no avail.
How do other developers discover how to fix problems like this when the technology stack presents so little information about what is actually happening?
How do I get this working?

Answer 1

I found and solved the problem, a network configuration issue completely outside axios/nodejs/react. The fact remains that I think it should somehow be possible for a developer to get at least a hint from the exception raised by axios.
For those who are interested, the problem turned out to be the AWS Security Group configuration for the new system. I had to open port 7003 in the Security Group, allowing access from my local IP address, in order for the request to be forwarded to the platform.
I suppose I should have thought of this sooner -- VSC spawns a special Chrome browser on my local system with its own private tunnel and such. It appears that that browser instance running on my local machine makes the request against port 7003. The AWS Security Group was blocking that port, and so the request never made it to the server.
I identified the issue by doing the wget from my local machine rather than from the new target EC2 instance. That failed, and then I attempted to connect with telnet. When the latter could not connect, I knew it was a Security Group issue.
The bottom line is that it is sometimes too easy to forget that ALL React code runs in the browser. I know that's obvious. but its implications sometimes are not.