VS402625: Dates must be increasing with each revision.. Bumped ChangedDate

[mwbryan101]

Describe the problem

I'm receiving this error when converting from Jira to ADO using release jira-azuredevops-migrator-3.0.558. When attachments on Index 0 (the header) are loaded into ADO, sometimes it retains the original date/time and sometimes it comes in as the current date/time. If it comes in as the current date/time, then when it tries to load the next index record 1 update, it returns this error in a never ending loop because it is still using the original date from 2 years ago. I suppose it would increment until the date/time is later than the current date/time, but that would take a very long time.

I also saw ticket 1125 about this same error, but it did not seem to fit and was closed due to lack of activity.

To Reproduce

Steps to reproduce the behavior:

1)In Jira, create a new 'Story' with multiple attachments in the header and save it.

2)Export the Story using jira-azuredevops-migrator-3.0.558.

3)Import the 'Story' into ADO (I had to map the Jira 'Story' to the ADO 'User Story')

4)You will receive the error. I killed the process using Ctrl C.

5)Look at the ADO User Story created and note one of the images retained the correct date/time and one is current.

The error is happening because Index 1 is dated 11/1/2023.

Tool version

• Version of the jira-azuredevops-migrator tool 3.0.558

Attachments

Please attach the following files:

• config.json
• jira-export-log.txt
• wi-import-log.txt

config-scrum_HSMN.json

jira-export-log-251024-112354.txt

wi-import-log-251024-130259.txt

Screenshots
If applicable, add screenshots to help explain your problem.

Added inline above.

[mwbryan101]

I started stepping through the log file and comparing it with what I see in the Jira source file and ADO. The first one processed was ATP-3651. It inserted 1 attachment with a current date/time (see screenshot). Then it updated the title for the Jira data and loaded revisions 1 and 2 (see screenshots). The second revision also had a current date/time which also would have caused a problem had it not branched to ATP-3652 and failed there first. It started failing trying to do the revision 0 update of the title because the current date/time was newer than the revision 1 date/time (10/31/2023). It seems to be losing track of the Revision date when doing multiple things (loading the base information, attachments, and updating the title). This may only be related to User Stories. So far that is the only place I have seen this behavior. Could it be related to your code not reflecting 'User Story' as a type and using 'Product Backlog Item' instead? I had to change the map from a Jira 'Story' to a ADO 'User Story' rather than an ADO 'Product Backlog Item' that was originally configured.

One other thing...We are using a 'Modified Scrum' process template which is a blend of Agile/Scrum methodologies. See the screenshot below.

ATP-3651 Attachment Screenshot:

ATP-2651 History:

ATP-3652 History:

Modified Scrum Process Template

[mwbryan101]

I also ran the export/import using the Agile configuration file. It had the same date/time sequencing issues.

[mwbryan101]

@Alexander-Hjelm I couldn't find a way to add a 'Bug' label. There are now 2 cases of this issue. Is it possible to add the 'Bug' label and have someone look at this? I have about 5,500 Jira tasks to convert and when it fails, I have to remove the file and start over...very disruptive in the process.

[mwbryan101]

@Alexander-Hjelm,

I did some more analysis. I changed the configuration parameter to "changeddate-bump-ms": 0 and re-ran the process for the group of 17. 6 were still reported as date/time sequence errors. In reviewing the log, all 6 had the following properties in common, which may help isolate the error (seems like attachments at the Index 0 level):

• The error occurred only at the Index 0 (header) level.
• The Index 0 date/time original creation date/time was correct.
• They had an attachment at the Index 0 level.
• The item description and inline attachments do not show up in the converted item.
• The error occurred after the attachments were processed and failed during the process that goes back and updates the title with the Jira item reference.
• As a result, not all of the header information is correct (sometimes the title, other times the Area/Iteration)
• All the images have current date/times.
• Processing continued on to the next Index but all date/times for subsequent revisions were current date/times.

Here is a sample portion of the log.

[I][08:33:36] Processing 12/314 - wi '1668', jira 'ATP-3653, rev 0'.
[I][08:33:36] Adding single attachment
[I][08:33:36] ID: ca0e8b0f-dce6-4e8d-9a8c-cd51706a7a6c
[I][08:33:36] URL: 'https://dev.azure.com/HSoAEnterpriseApplications/_apis/wit/attachments/ca0e8b0f-dce6-4e8d-9a8c-cd51706a7a6c?fileName=image-20231031-160354.png'
[I][08:33:36]
[I][08:33:36] Updated Existing Work Item: '1668'. Had 3 attachments, now has 1
[I][08:33:36]
[I][08:33:36] Adding single attachment
[I][08:33:36] ID: ecd4eae2-87c5-445f-a31e-67ea11207b60
[I][08:33:36] URL: 'https://dev.azure.com/HSoAEnterpriseApplications/_apis/wit/attachments/ecd4eae2-87c5-445f-a31e-67ea11207b60?fileName=image-20231031-160417.png'
[I][08:33:36]
[I][08:33:37] Updated Existing Work Item: '1668'. Had 1 attachments, now has 2
[I][08:33:37]
[I][08:33:37] Adding single attachment
[I][08:33:37] ID: a876a706-b955-41a1-b05d-5f6f6b10aa83
[I][08:33:37] URL: 'https://dev.azure.com/HSoAEnterpriseApplications/_apis/wit/attachments/a876a706-b955-41a1-b05d-5f6f6b10aa83?fileName=image-20231031-160440.png'
[I][08:33:37]
[I][08:33:37] Updated Existing Work Item: '1668'. Had 2 attachments, now has 3
[I][08:33:37]
[E][08:33:37] VS402625: Dates must be increasing with each revision.
[E][08:33:37] Work Item 1668 failed to save.
[I][08:33:37] Processing 13/314 - wi '1668', jira 'ATP-3653, rev 1'.
[I][08:33:38] Updated new work item Id:1668 with link to work item ID:1667

Here is a screenshot of the resulting ADO item.

[mwbryan101]

I ran the whole batch in our test environment last night. There were 5,320 items with 103,840 revisions. There were 179 errors and 5,621 warnings. The load took 9 hours and 22 minutes…partly due to ADO throttling me back for using so many resources.

Most of the errors were the same date/time sequence errors and also had the same properties as identified earlier in this tread. It was not as prevalent as I had feared. Changing the config setting ("changeddate-bump-ms": 0) was key to getting through this full load.

I think we will convert and fix the errors manually online. I still think it would be good for someone to fix this issue.