Transitions d'état qui disparaissent aléatoirement

Je suis seule sur l’application
Non il n’y a pas de changement de langue
J’ai ajouté la trace
Et par curiosité je suis restée idle 30 minutes pour voir si je reproduisais, mais non :-/

Je regarderai ce qu’il y a dans les logs à la prochaine erreur, merci !

Ok tiens nous au courant de tes tests.
Si tu es en dev/designer en cours de paramétrage, c’est possible de casser le core-cache après des rechargements partiels d’objets, listes…, on ne peut pas y faire grand chose, il faut refaire un CC global. Mais ça ne doit pas se produire en production si personne ne vide jamais le cache.

De mon côté j’ai essayé de reproduire avec un héritage qui utilise le même state model et habilité à 2 objets, mais aucune transition ne se perd.

Il faudra regarder les taches cron qui passent pendant la période d’inactivité, si vous avez des traitements particuliers.

C’est arrivé aussi en production oui, c’est pour ça que je t’embête autant pour tenter de comprendre car c’est environ toutes les semaines.
Là ça n’est pas réapparu sur la dev depuis mon dernier retour, même après une période d’inactivité.

Bonjour François,

Je viens d’avoir de nouveau le souci après une période d’inactivité.
Voici les traces.
Le cache semble renvoyer les transitions du 3ème objet hérité (qui en effet ne les a pas perdues). Les autres ne sont plus là.

AppLog.info("Loop postSave wkf " + CoreCache.getInstance().getTransitions(getGrant().getLang(), "RCIAPPRECORDSTATUS"), getGrant());```

> 2024-12-03 13:27:41,061|SIMPLICITE|INFO||http://simplicite-dev-67bb8cd5f9-7v6cl:8080||INFO|designer|com.simplicite.commons.RCIB.RciWorkflowObject|postSave||Event: Loop postSave wkf [STATE TRANSITION : from=DRAFT, to=TOBEVALID, groups=[
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> ], STATE TRANSITION : from=TOBEVALID, to=DRAFT, groups=[
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> ], STATE TRANSITION : from=TOBEVALID, to=VALID, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_METHODS
> ], STATE TRANSITION : from=TOBEVALID, to=TOREVIEW, groups=[
> 	RciAccountableAppsub:RCI_RESP_APP
> ], STATE TRANSITION : from=TOBEVALID, to=TOREVIEW, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_METHODS
> ], STATE TRANSITION : from=VALID, to=TOREVIEW, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> ], STATE TRANSITION : from=TOREVIEW, to=TOBEVALID, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_RESP_APP
> ]]
AppLog.info("Loop postSave wkf 1 " + fst.getGroups().size(), getGrant());`

> 2024-12-03 13:27:41,061|SIMPLICITE|ERROR||http://simplicite-dev-67bb8cd5f9-7v6cl:8080||ERROR|system|com.simplicite.util.ObjectHooks|postSave||Event: Implementation error in the postSave hook of object RciAppSub
> java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because the return value of "com.simplicite.util.FieldStateTransition.getGroups()" is null
> 	at com.simplicite.commons.RCIB.RciWorkflowObject.postSave(RciWorkflowObject.java:385)
> 	at com.simplicite.objects.RCIB.RciAppSub.postSave(RciAppSub.java:361)

Pour info, la log après un Clear cache

> 2024-12-03 14:24:28,865|SIMPLICITE|INFO||http://simplicite-dev-67bb8cd5f9-7v6cl:8080||INFO|designer|com.simplicite.commons.RCIB.RciWorkflowObject|postSave||Event: Loop postSave wkf [STATE TRANSITION : from=DRAFT, to=TOBEVALID, groups=[
> 	RciApplication:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> 	RciAppSub:RCI_SUPER_ARCHITECT
> 	RciApplication:RCI_SUPER_ARCHITECT
> 	RciAppSub:RCI_PROFILE_SUPER_RRSG
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciAppSub:RCI_RESP_APP
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciApplication:RCI_RESP_APP
> ], STATE TRANSITION : from=TOBEVALID, to=DRAFT, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> 	RciAppSub:RCI_SUPER_ARCHITECT
> 	RciApplication:RCI_SUPER_ARCHITECT
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciApplication:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciAppSub:RCI_RESP_APP
> 	RciApplication:RCI_RESP_APP
> ], STATE TRANSITION : from=TOBEVALID, to=VALID, groups=[
> 	RciApplication:RCI_ARCHITECT
> 	RciApplication:RCI_SUPER_ADMIN
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciApplication:RCI_ARCHITECT_CORP
> 	RciAccountableAppsub:RCI_METHODS
> 	RciAppSub:RCI_RRSG
> ], STATE TRANSITION : from=TOBEVALID, to=TOREVIEW, groups=[
> 	RciAppSub:RCI_RRSG
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciApplication:RCI_SUPER_ADMIN
> 	RciApplication:RCI_ARCHITECT
> 	RciAccountableAppsub:RCI_METHODS
> ], STATE TRANSITION : from=TOBEVALID, to=TOREVIEW, groups=[
> 	RciApplication:RCI_RESP_APP
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciAppSub:RCI_RESP_APP
> ], STATE TRANSITION : from=VALID, to=TOREVIEW, groups=[
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciApplication:RCI_SUPER_ADMIN
> ], STATE TRANSITION : from=TOREVIEW, to=TOBEVALID, groups=[
> 	RciAppSub:RCI_SUPER_ARCHITECT
> 	RciApplication:RCI_RESP_APP
> 	RciAppSub:RCI_RESP_APP
> 	RciAccountableAppsub:RCI_RESP_APP
> 	RciApplication:RCI_SUPER_ADMIN
> 	RciAppSub:RCI_SUPER_ADMIN
> 	RciAccountableAppsub:RCI_SUPER_ADMIN
> 	RciAppSub:RCI_PROFILE_SUPER_RRSG
> 	RciApplication:RCI_SUPER_ARCHITECT
> 	RciAccountableAppsub:RCI_SUPER_ARCHITECT
> ]]

Merci pour ton retour.

Donc on perd des transitions dans le core-cache pour certains objets hérités.
Ce cache est sensé être static une fois chargé ou désérialisé, donc il doit y avoir un rechargement partiel/tronqué à un moment donné.

On va regarder dans ce sens.

1 Like

Après analyse il ne peut y avoir que 2 causes :

  1. rechargement des définitions de transitions : clear-cache partiel d’un des objets (ici RciAccountableAppsub)

  2. mauvaise langue de getGrant().getLang() : changement de langue du user pendant la session, mais dans ce cas je ne vois pas trop pourquoi il ne resterait qu’1 objet et pas 0.

On va améliorer le 1) pour qu’un clear-cache partiel le soit un peu moins au niveau des transitions.

Par contre pour savoir pourquoi ?

  • il faut regarder si vous faites un select/save sur cet ObjectInternal par code ou alors vous modifiez un ENUM de cet objet à la volée, ou au sens large changez la définition d’une entité reliée à cet objet métier par code…
  • sinon c’est que qqun fait des modifications applicatives en prod en tant qu’ADMIN (via la UI ou import XML sur un truc relatif à RciAccountableAppsub) et sans vider tous les caches derrière.

Je vois ceci en termes de CC partiel dans les logs qui précèdent la survenue du bug, est-ce que ça pourrait être l’un de ceux là ?

||INFO|system|com.simplicite.objects.System.Script|partialClearCache||Event: Partial clear cache for shared code RciCommonObject
||INFO|designer|com.simplicite.objects.System.ObjectInternal|partialClearCache||Event: Partial clear cache for object RciApplication
||INFO|system|com.simplicite.objects.System.Field|partialClearCache||Event: Partial clear cache for field rciFieldIsBackup
||INFO|system|com.simplicite.objects.System.SystemParam|partialClearCache||Event: Partial clear cache for sysparam RCI_APPSUB_TECHNICAL_ID_DEV=484

Oui RciAccountableAppsub a dû passer en dernier puisqu’il n’y a plus que lui dans les transitions connues.

On va forcer un rechargement global des Transitions même en cas de CC partiel d’un objet métier.
C’est trop compliqué d’aller remplacer qu’une partie des droits de transitions en raison des héritages potentiels à N niveaux.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.