Server fails to answer on integration server

[ttben]

On the deployed integration server, the server either

• fails to answer, no answer are provided
• takes waaayyyy too long to answer (see image below)
• or answer with an empty response (see image below)

The client should definitely handle this use-case... but on the other hand this should not happen at the integration stage O:)

[ttben]

After refreshing 3-5 times it eventually works.. -o-

[ttben]

When failing (reason still unknown), foreverjs tries to restart the server (that basically crashed).
Sometimes, it works!
Sometimes, it doesnt.

I logged via SSH and connect to the screen section, here is the displayed message

> [email protected] start /var/www/server
> forever forever/config.json

warn:    --minUptime not set. Defaulting to: 1000ms
warn:    --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
Could not store data
Missing data
error: Forever detected script exited with code: 0
error: Script restart attempt #1
Your server is listening on port 8080 (http://localhost:8080)
Swagger-ui is available on http://localhost:8080/docs
Could not store data
Missing data
error: Forever detected script exited with code: 0
error: Script restart attempt #2
Could not store data
Missing data
error: Forever detected script exited with code: 0

I'll dive into the server's code to check where and why there is a "could not store data" and then a "missing data" issue.

[ttben]

The disk is not full.
I am not sure about what the /dev/loopX nor the tmpfs are, but sda1 seems ok

Filesystem      Size  Used Avail Use% Mounted on
udev            954M     0  954M   0% /dev
tmpfs           194M  980K  194M   1% /run
/dev/sda1        39G  5.7G   33G  15% /
tmpfs           970M     0  970M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           970M     0  970M   0% /sys/fs/cgroup
/dev/sda15      105M  9.1M   96M   9% /boot/efi
/dev/loop0       55M   55M     0 100% /snap/core18/1880
/dev/loop1       72M   72M     0 100% /snap/lxd/16100
/dev/loop2       30M   30M     0 100% /snap/snapd/8140
tmpfs           194M     0  194M   0% /run/user/1000
/dev/loop3       56M   56M     0 100% /snap/core18/1885
/dev/loop4       30M   30M     0 100% /snap/snapd/8790

[ttben]

It seems that the backend's backend, the API called by the backend; is not responding?
Is that it?
The error starts here

I will log what the API actually returned.
As this does not happen locally, I will test in the integration branch..

[ttben]

So actually, this is due to an API limit reached.

This was obviously a bad idea to ping real backend's API during development, integration AND production phase..

[{"errorcode":10006,"reset_time":"2020-09-23T00:00:00Z","limit_time_unit":"day","call_limit":2000,"error":"You have exceeded your quota of 2000 api calls per day on this dataset."},{"errorcode":10006,"reset_time":"2020-09-23T00:00:00Z","limit_time_unit":"day","call_limit":2000,"error":"You have exceeded your quota of 2000 api calls per day on this dataset."}];

[PETILLON-Sebastien]

Shit.
So we'll need an API key ? How does it work ?

[rte-opendata]

Yep ... shit, indeed.
I confirm your diagnostic : I put a daily limit for anonymous API calls on éCO2mix datasets published on https://opendata.reseaux-energies.fr/. Please, see issue #74
RTE open data team.