Unclear synchronization error with Xsquash4GitLab

[andrev312]

I've been using Squash Community edition for several months and recently updated to v6. I also have a GitLab repo from which I have been synchronizing issues succesfully until a week ago.
For some unclear reason, the synchronization is now failing with this error on top:
org.hibernate.AssertionFailure: null id in org.squashtest.tm.domain.attachment.Attachment entry (don't flush the Session after an exception occurs)

The full synchronization error log is attached

Any hint, tip or help is appreciated
Thanks,
André

[xdevroedt]

Hello,

When you upgraded your Squash version, did you update all the plugins on your instance to version 6 (in particular xsquash4gitlab)? You can get a quick overview from Administration > System > Information)

Are the logs you have sent us from the new synchronisations supervision page (Administration > System > Synchronisations supervision)?

For requirements that have already been synchronised in Squash, is the colour of the double arrow (synchronisation status) red or black (in the root folder and in the requirements themselves) ?

Best regards,
Xavier, Squash Support Team

[andrev312]

Hi Xavier,

I did upgrade all plugins as well indeed and the log file attached was the logfile from the new synchronization supervision page (which I do like very much by the way).

The synchronization status for the already synced requirements is red for the root folder and black for all requirements underneath (in folders based on Milestones in GitLab).

As an additional check I just created the same synchronization again, with a different name but exact same settings: When doing a 'simulation' it runs fine and does show result but when actually adding the new synchronization it fails as well.

Best regards,
André

[xdevroedt]

Hello,
We have sent your logs to our developers for analysis.
We look forward to receiving as much information as possible:

• what type of gitlab do you use for your synchronisations (cloud, server + community, premium)?

• have you set equivalences in your plugin configuration on your Squash project (the 2 blocks immediately below the 'Synchronisations' block)?

• In a new Squash project, can you recreate your synchronisation on a scope identical to the previous one, without filling in any of the equivalence blocks in the rest of the plugin configuration and tell us if the synchronisation is successful? Before validating it, what does the simulation tell you?

Best regards,
Xavier, Squash Support Team

[andrev312]

Hello Xavier,

The GitLab used is GitLab CE (Community Edition) version 15.10.

We do use 'equivalences'. The first part is captured in the image attached, the second part is:
status:
In review: under_review
Requirement change pending: under_review
In progress: work_in_progress
Done: approved
Rejected: obsolete

category:
Feature: cat_use_case
User story: cat_user_story
Task: cat_technical
Functional Requirement: cat_functional
Non-functional Requirement: cat_non_functional
Information: cat_test_requirement

criticality:
High: critical
Medium: major
Low: minor

So yes, we have labels in GitLab containing whitespaces but this has been working for a couple of months so I doubt that's a problem.

For the simulation in a sandbox project I'll check and come back to that.

regards,
André

[andrev312]

I've also trie recreating the synchronization in a sandbox project. Same server, same settings but no equivalences set.
Simulation is successful, see image. Synchronization itself fails with same reason and logging as before.
André

[xdevroedt]

Hello,


- Does the Gitlab search on the same perimeter as your simulation return the same number of tickets (i.e. 182)?
- Did the synchronisation immediately 'Fail' following the version upgrade, or did it run for a while?
- What does the 'synchronized successfully on' field return for your synchronisation?


There seems to be a problem with the update action in the initial logs.
So we're going to try to proceed by successive elimination to find out if one or more tickets could be responsible for this failure (in particular because of a character in the title).
The aim will be to create new synchronisations on smaller perimeters and see when one of these synchronisations fails (then refine the perimeter again, etc.). To do this:

- From the Gitlab search, sort the tickets concerned by the synchronisation by 'Updating date' 'Descending' and see if one or more tickets could fall into the same time zone as the 'synchronised successfully on' then try to synchronise them separately (still in the test project).
- Try to create synchronisations on the same perimeter as before, but with additional filters.
- If you have a delta between the number of tickets simulated and the number of tickets in your search, try to synchronise the tickets that are not present separately.


Best regards,
Xavier, Support Team

[andrev312]

Hi,

Some answers:
- Does the Gitlab search on the same perimeter as your simulation return the same number of tickets (i.e. 182)?
--> No, it does not. The simulation mentions a lower number than present in GitLab (with the same filters applied)

- Did the synchronisation immediately 'Fail' following the version upgrade, or did it run for a while?
--> No, it did not. It ran for a while and started to fail at a certain date

- What does the 'synchronized successfully on' field return for your synchronisation?
--> For the initial failure resulting in this thread: It started to fail on Feb 13th. For new synchronizations I tried later on, the 'synchronized successfully on'is 'never'

Doing al kind of checks in a test project, e.g. synchronizing all sub-projects in a group seperately already did result in identifying the subprojects having issues. Als noticed that an é character in a title gives issues. Still not fully succesful thus, continuing by trying to sync missing issues one-by-one.

Best regards,
André