Scripts Rhino 6.3.11

Request description

Bonjour,

Lors du passage à la mise à jour 6.3.11, sur plusieurs de nos projets, des scripts Rhino internes bloquaient le passage de nos pipelines. Le pod tente indéfiniment de redémarrer. J’ai bien vu dans les release notes que ce blocage était prévu par cette mise à jour en revanche mon interrogation porte sur le fait qu’il semble s’agir de scripts éditeur. Les deux concernés étaient “responsive.js” de l’objet Disposition et “WebNews.js” de ObjectInternal. Je suis temporairement revenu à la 6.3.10 et supprimé les scripts. Pouvez-vous me confirmer que le fait de les avoir supprimé dans la liste des documents n’aura pas d’incidence ?

Merci

Steps to reproduce

This request concerns an 6.3.11 Simplicité instance
and these are the steps to reproduce it:

Technical information

Instance /health
---paste the content of your-instance.com/health---
Simplicité logs
---paste the content of the **relevant** server-side logs---
Browser logs
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

Bonjour

Oui aucun pb supprimer les éventuels scripts Rhino résiduels.

Ce qui m’étonne c’est que ça ne se soit pas fait automatiquement lors de l’application des patches système du démarrage car ils contiennent une requête pour “faire le ménage” sur ce point.

Pour qu’on puisse investiguer plus précisément, pouvez vous:

  1. nous indiquer la révision exacte de départ de votre upgrade
  2. nous indiquer le type et la version exacte de la base de données utilisée

Pouvez vous aussi nous indiquer ce que vous avez fait pour supprimer ces scripts Rhino ?

La révision de départ était la 6.2.26 et la base de données est PostGreSQL 14.

Pour supprimer les scripts, je les ai supprimé de la liste des documents des objets Disposition et ObjectInternal est-ce suffisant ?

Nous ne voyons pas de scripts Rhino résiduels sur une instance 6.2.26 out of the box déployée sur une base PostgreSQL 14

Précédemment votre instance aurait-elle été upgradée depuis une v5 ? voire avant depuis une v4 ?

Nous essayons de comprendre d’où viennent et comment ont pu persister ces fichiers résiduels.

Je comprends que vous les avez supprimés les records en question de l’objet Document , est-ce bien le cas ? Si oui ça devrait être bon.

Oui nos instances étaient précédemment en V5.

Merci pour vos réponses !

Vous rappelez vous quelle était la révision v5 à l’époque où vous êtes passés en v6 (et la révision cible v6 en question) ?

Je pose la question car en testant un upgrade de la v5 à jour à la date de release de la 6.2.26 (= 5.3.86) vers la 6.2.26 (révision finale de la 6.2) puis vers la v6 à jour (= 6.3.12) on n’a toujours pas de scripts Rhino résiduels à l’arrivée (la purge d’éventuels script Rhino est faite dès l’étape 6.2 et de toute façon refaite à l’étape 6.3). Bref on ne voit pas trop comment il peut y avoir des scripts Rhino résiduels dans votre cas.

Il faudrait donc reconstituer la séquence exacte des upgrades successifs que vous avez faits au fil du temps pour voir où il peut y avoir eu un raté.

Bonjour,

J’ai eu le même problème sur un passage d’une 5.3.91 à une 6.3.11 en autoupgrade. J’ai joué cette requête suite à l’arrêt du tomcat :

delete from m_document where dbd_path like '%responsive.js%';

delete from m_document where dbd_path like '%WebNews.js%';

puis rédémarrage du tomcat.

La requête suivante est pourtant dans les patches système “clean database” de la 6.3:

-- Just in case, remove any outstanding Rhino script
delete from m_document
where dbd_path like 'Script/scr_file/%.js'
or dbd_path like 'Adapter/adp_script_id/%.js'
or dbd_path like 'Disposition/dis_script_id/%.js'
or dbd_path like 'ObjectInternal/obo_script_id/%.js'
or dbd_path like 'ObjectExternal/obe_script_id/%.js'
or dbd_path like 'BPMProcess/pcs_script_id/%.js';
commit;

Vous êtes sur quelle base (tyep et version) ?

J avais fait la migration depuis 5.3.91 à une 6.3.11 puis je suis passé en 6.3.12 suite à sa sortie. Ci dessous le health :

[Platform]
Status=OK
Version=6.3.12
Variant=full
BuiltOn=2026-07-10 14:31
Git=6.3/0681f8aa25ccb834c0374086f5dd8ccb01197337
Encoding=UTF-8
EndpointIP=10.105.79.40
EndpointURL=http://XXXXXXXXXX/simplicite
TimeZone=Europe/Paris
SystemDate=2026-07-21 11:01:52

[Application]
ApplicationVersion=6.3.0
ContextPath=/simplicite
ContextURL=https://XXXXXXXXXX/simplicite
ActiveSessions=1
TotalUsers=80
EnabledUsers=42
LastLoginDate=2026-07-21 11:00:08

[Server]
ServerInfo=Apache Tomcat/9.0.87.redhat-00003
ServerType=WEB
ServerDevMode=true
ServerCompiler=true
ServerActiveSessions=0
ServerSessionTimeout=30
CronStarted=true

[OS]
Name=Linux
Architecture=amd64
Version=5.14.0-687.17.1.el9_8.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=2958
DiskUsable=2958
DiskTotal=3062

[JavaVM]
Version=21.0.11
Vendor=Red Hat, Inc.
VMName=OpenJDK 64-Bit Server VM
VMVersion=21.0.11+10-LTS
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=179365
HeapSize=1287168
HeapMaxSize=2097152
TotalFreeSize=989349

[Cache]
ObjectCache=388
ObjectCacheMax=10000
ObjectCacheRatio=3
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=3
VendorName=postgresql
ProductName=PostgreSQL
ProductVersion=16.14
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.3.9
DBDate=2026-07-21 11:01:52
DBDateOffset=0
DBPatchLevel=6;P03;8e770eada1f9642abb8fa2c190e1de9d;12
UsingBLOBs=true

[Healthcheck]
Date=2026-07-21 11:01:52
ElapsedTime=25

La requête de clean est présente depuis longtemps, on va retester pour comprendre pourquoi elle ne s’execute pas ou trop tard