Inconsistent responses from API container -> DataTables errors

[Chatewgne]

Describe the bug

Several users encounter DataTables errors in the interface across all modules.

These errors do not appear in the internal app logs or through Sentry.

We have identified that the server returns inconsistent responses from the API container, leading to many 500 responses when there are no actual errors in the logs.

In the following example we receive status 200 (expected geojson data) or 500 (internal server error) when refreshing, even though nothing changed in between the requests and all responses should be status 200 with correct data.

The command docker compose restart api can be used to fix this, but the behavior is likely to happen again after some time.

Restarting nginx and emptying the web cache do not change this behavior, thus an internal problem in that container is suspected.

[eprouteau]

Bonjour, j'obtiens ce comportement également. Est ce que la commande docker compose restart api est valable également avec une installation de l'admin sans docker ?

[babastienne]

Bonour @eprouteau un redémarrage complet de l'application peu également résoudre le problème. En lançant par exemple la commande sudo systemctl restart geotrek dans le cas d'une installation sans docker.

[eprouteau]

j'avais tenté sans succès j'ai aussi reboot nginx. ces reboot on d'ailleur mis en vrac geotrek-rando qui fonctionnait malgré les erreurs de l'admin

Je mets à jour mes données via QGIS, est ce que un problème de base peux avoir eu une impact ?

je suis en version 2.107.1 et mis à part un ajout de trek via qgis (car pas en segmentation dynamique) je n'ai strictement rien touché au server.

Quels logs pourraient êtres parlant car ceux de geotrek-admin ne contiennent rien

[camillemonchicourt]

Je n'ai pas croisé le soucis de mon côté. En effet, cela indique que le tableau listant les données (datatable) n'arrive pas à afficher les données renvoyées par la BDD. En effet si des données sont intégrées directement dans la BDD, le soucis peut venir de cela, si certains champs attendus par l'application ne sont pas remplis ou mal remplis, mais je n'ai aucune certitude.

[eprouteau]

Je voulais tester avec une base de données vierge justement pour éliminer ou non cette potentielle cause mais n'en ai pas à dispo.

Auriez vous une méthode pour regénérer une BDD vierge sans toucher aux autres config ?

[submarcos]

Pour apporter des précisions, cette "erreur" n'est pas une erreur. C'est un comportement qui révèle une potentielle multitude d'erreurs. Je m'explique : cela signifie simplement que l'interface web n'arrive pasà charger les éléments de la table via l'API de geotrek.

Cela peut provenir d'une multitude d'erreurs, ce n'en est pas une seule.

Quelques exemples ayant récemment provoqué cette erreur :

• le service memcached était down
• bug sur l'intersection géographique des interventions (cas particulier des filtres par zonage)
• bug d'une certaine version de sentry-sdk (geotrek admin < 2.107.1)

En aucun cas on ne peut généraliser ce symptome à un problème.

Pour trouver la solution à votre problème, il faut tout d'abord regarder l'origine de l'erreur.

Erreur 500 : regarder dans les logs api, geotrek.log (ou container api en cas de docker) Erreur 504 / 502 : problèmes de proxy (communication entre nginx / gunicorn). Soit un probleme de timeout (nginx / gunicorn), soit un probleme qui termine un process gunicorn (mémoire, segfault, ça arrive souvent avec les 502), soit une mauvais configration avec docker (pas assez de workers)

[eprouteau]

Merci pour ces pistes,

Voulant un dump de base vierge j'ai réinstallé un geotrek admin. J'ai ensuite rétabli ma config initial via un snapshot.

La piste mémoire est peut être à creuser