Forum SquashTM

version affectée : Squash TM 14.0.3 / 14.0.4 (Docker image squashtest/squash) Composant : tm.service — org.squashtest.tm.service.internal.repository.hibernate.MilestoneDaoImpl

Etapes pour reproduire l'erreur :
On a Squash TM 14.0.3/14.0.4 instance (milestones feature not even required to be in use — reproduces with 0 milestones in the database).
Open any test case with at least zero existing steps.
Add a new action step / prerequisite and save.
Observe "Une erreur imprévue est survenue" in the UI; server logs show the stack trace above.


Comportement observé :
Adding a new test step (action step / prerequisite) to a test case systematically fails with a NOT NULL constraint violation on test_case_steps.test_case_id, even on an instance with zero milestones defined. Reproduces on a test case with no pre-existing steps (empty list), ruling out any data corruption or step-ordering issue.
Stack trace (root cause) : Caused by: org.postgresql.util.PSQLException: ERROR: null value in column "test_case_id" of relation "test_case_steps" violates not-null constraint Detail: Failing row contains (null, 39151, null). [insert into public.TEST_CASE_STEPS (STEP_ID) values (?)]
Call chain (from the full stack trace) : CheckBlockingMilestoneAspect.checkBlockingMilestone -> MilestoneDaoImpl.isTestStepBoundToBlockingMilestone(long) -> org.jooq.impl.DefaultDSLContext.fetchCount(...) -> JooqSessionGuard.executeStart(ExecuteContext) -> Hibernate Session.flush() (forced, session was dirty) -> premature INSERT of the incomplete test_case_steps row -> PSQLException: NOT NULL violation
Root cause : JooqSessionGuard (tm.service, @Since SquashTM 2.0) intentionally forces a Hibernate session flush before every jOOQ query execution, to avoid stale reads when the session is dirty. This is legitimate and documented behavior. However, MilestoneDaoImpl.isTestStepBoundToBlockingMilestone is the only one of the ~15 sibling "isXxxBoundToBlockingMilestone" methods in MilestoneDaoImpl that is implemented via jOOQ (dsl.fetchCount(...)); all the other ones (isRequirementBoundToBlockingMilestone, isCampaignBoundToBlockingMilestone, isExecutionStepBoundToBlockingMilestone, etc.) use plain JPA/HQL named queries and do not trigger JooqSessionGuard.

Nous utilisons une Azure database PostgreSQL flexible server en version 15.18.

Bonjour,
Pouvez-vous passer la requête suivante sur votre base de données : EDIT : quelle est la version de Java qui tourne sur votre environnement ?

Cordialement,
Xavier, Equipe Support SquashTM

Voici le résultat de la requête ( fichier joint )

Nous utilisons la version jdk-21.0.10+7

Bonjour,
Nous sommes entrain d'analyser vos logs et fichiers de requetes fournis.
Dans l'attente, pouvez-essayer de mettre à jour votre version de Java (à minima la version 25 pour SquashTM v14.X) et dans une moindre mesure votre version de Postgres (17 recommandé pour pour SquashTM v14.X) : https://tm-fr.doc.squashtest.com/latest ... #prerequis ?

Cordialement,
Xavier, Equipe Support SquashTM

Bonjour,
En plus des modifications proposées ci-dessus, avez-vous paramétré une propriété de ce style dans votre fichier de déploiement/conf ? : A priori, nous avons réussi à reproduire votre problème avec cette propriété, qui rentre en conflit avec le déploiement et la configuration normale de SquashTM.

Cordialement,
Xavier, Equipe Support SquashTM

Merci pour vos retours, je vous confirme que l'anomalie persiste en version postgres 17.10 et en java 25.
J'ai bien la ligne spring.jpa.properties.hibernate.default_schema dans mon entrypoint.sh

pour etre exacte j'ai ceci :
-Dspring.jpa.properties.hibernate.default_schema="${SQTM_DB_SCHEMA:-public}"
dans une commande exec java.

Cordialement

Bonjour,
Le problème provient bien, à priori, de cette ligne là.
Dans votre contexte, pouvez-nous nous expliquer les utilisations de cette ligne de configuration additionnelle ?

Cordialement,
Xavier, Equipe Support SquashTM

Nous avons réalisé beaucoup d'actions migration et upgrade de l'application en peu de temps, nous étions encore en version 5.0 il y a moins d'un mois, et nous étions passé par un script liquibase pour des actions. Je vous confirme qu'après avoir retiré la ligne, et testé, l'erreur n'est plus présente. J'attend le retour de nos utilisateurs de l'outils pour vous confirmer si tout est résolu ou non.

Cordialement,

j'ai reçu la confirmation de nos utilisateurs, l'outil fonctionne bien sans soucis.

Merci a vous, et merci pour vos analyses.

Cordialelment,

Bonjour,
En vous remerciant de votre retour, nous sommes ravis que cela fonctionne à nouveau correctement chez vous.
Je vais clôturer le ticket gitlab ouvert.
Cordialement,
Xavier, Equipe Support SquashTM