Bonjour,
Nous rencontrons une erreur “étrange” lorsqu’on cherche à suspendre une licence d’utilisateur :
2022-02-15 17:47:02,684|SIMPLICITE|ERROR||http://siparex-simplicite-dev-745fcf686c-b58k5:8080||ECORED0001|designer|com.simplicite.webapp.ObjectDocument|displayFile||Erreur File from input stream
java.lang.NullPointerException: Cannot invoke “java.io.InputStream.read(byte)” because “in” is null
at com.simplicite.webapp.tools.ServletTool.writeStream(ServletTool.java:2698)
at com.simplicite.webapp.ObjectDocument.displayFile(ObjectDocument.java:337)
Je ne constate pas de pb quand je fais ça sur une 5.1.29 “out of the box”
Pouvez vous nous fournir le stacktrace complet de l’erreur ? Sans cela on ne peut pas situer précisément le cas d’erreur.
Et/ou nous indiquer plus d’informations contextuelles sur votre cas d’usage (avec quel user êtes vous connecté ? sur quel scope ? etc.), à noter que, souvent, une copie d’écran complete nous permet de mieux cerner ce contexte contrairement à un bout de copie d’écran.
De manière générale plus vous nous fournissez d’informations plus on est à même de cerner votre cas d’usage et, si possible, de le reproduire.
Sur l’objet User standard le seul attribut “document” (au sens large = document ou image) c’est la photo du user, peut être que le document photo de ce user est corrompu d’une manière ou d’une autre.
Essayez d’uploader manuellement une image dans la photo, enregistrez, et regardez si vous avez toujours cette erreur.
S’il n’y a plus l’erreur il faudra essayer de comprendre l’origine de la “corruption” de la photo (ex: avez vous une synchro auto depuis un IdP ? si oui l’attribut picture du userinfo contient elle quelque chose d’exploitable ? etc.)
NB: La console “Network” du navigateur permettrait de cerner plus précisément les attributs d’appel au service “document” en question, sans cela je ne peux pas être sûr qu’on parle bien de la photo du user
J’ai essayé d’uploader manuellement une photo et d’enregistrer. J’ai ensuite essayé d’activer le compte (ou de le suspendre), et j’ai toujours la même l’erreur.
Votre copie d’écran indique à priori que le pb concerne bien la photo du user. Mais je ne vois pas de raison qu’il y ait 3 appels au service “document” sur l’affichage du formulaire…
Pouvez vous refaire un test d’affichage du formulaire d’un user avec une photo uploadée manuellement et nous fournir l’export HAR correspondant de la console network (merci de mettre uniquement les traces correspondant à cet affichage du formulaire = supprimer les traces précédentes avant de faire la manip)
PS: Merci aussi de nous fournir le health check complet de votre instance.
Merci pour la copie d’écran de la console console du navigateur mais ce n’est qu’une une remontée partielle des logs serveur via websocket, donc le stacktrace fourni précédemment donne plus d’infos.
OK merci pour le health check complet ça va me permettre de monter un environnement de test le plus iso possible avec le votre.
L’objectif est, comme pour toute sollicitation de ce type, d’essayer de reproduire l’erreur que vous décrivez, ce que je n’ai pas réussi à faire jusqu’ici.
Par exemple, avec les infos fournies jusqu’ici je ne pouvais pas savoir que votre base de données était du PostgreSQL.
C’est pour cela qu’on vous demande de fournir le maximum d’informations tout de suite pour pouvoir reproduire le pb dans un environnement similaire au votre et avec un mode opératoire identique.
Bon test fait sur une image Docker 5.1.29 et sur un PostgreSQL 11.x (chez moi c’est un 11.15 pas un 11.14 comme chez vous mais ça ne doit pas changer grand chose):
J’ai créé un user avec une photo (par acquis de conscience j’ai essayé avec un PNG et un JPG) et sans photo, je n’ai jamais l’erreur que vous indiquez lorsque j’active et je désactive ce user.
Le User doit avoir physiquement dans le champ une image absente du dbdoc.
On ne voit rien sur la UI, mais il doit tenter de l’afficher avec un lien mort.
Il faudrait voir en base :
ce que contient la colonne usr_image_id de ce user
et si ça existe dans la table m_document s’il y a un fichier sur ce champ et ce user
Un changement d’état UI reste un appel Ajax d’update avec un nouveau statut, donc ça devrait aussi se produire sur un Save simple en sélectionnant un autre statut ou champ.
Mais bon jamais un GET affichage d’image KO ne bloque un call POST d’update.
Pouvez vous nous donner les données du call de cet update ?
Est ce l’objet User natif ou un héritier avec des choses en plus ?
ou avez vous modifié des choses dans l’objet User directement (ajout de champs, modif du template…) ?
De mon point de vue les logs n’ont rien à voir avec le pb de transition (droit, quota ou autre).
Les appels de la copie d’écran sont triés par ordre alphabétique donc inexploitables pour identifier le GET qui plante avec ses paramètres et à quel moment précis. Ils vous donneront les infos (comme le doc id et le row_id du record) qu’il faudra aller investiguer par ailleurs.
Donc surement un fichier manquant dans m_document où la colonne du BLOB (input stream) est null.
Là rien ne dit pas quel fichier est manquant, si ça se trouve c’est autre chose, une icone, un logo.
On voit aussi une requête sur un treeview sans nom, étrange : “app?action=treeview&name=”
Si c’est un pb d’upload, quand on enregistre une image, il faut regarder la taille disque, ou la config des BLOB de la base.
Je viens de faire plusieurs tests et l’erreur n’apparaît pas systématiquement quand je clique sur l’action suspendre ou activer. Cependant, que l’erreur apparaisse ou non, je ne peux pas suspendre ou activer un utilisateur.
Donc il est possible que le problème ne vienne pas de l’erreur mais d’autre part.
Si le problème vient effectivement d’autre part, je m’occuperai de l’erreur “InputStream” plus tard. Pouvoir activer et désactiver les utilisateurs est plus important que régler l’erreur.
