Closed rmwilkins closed 9 months ago
This sounds like an issue to me...
@rmwilkins I had a similar issue and did some investigation. It seems that the migration tool migrates work items to their original type before changing if the SkipToFinalRevisedWorkItemType key is set to false. However, if the key is true, it migrates the work items to the new changed type.
This is an example of a work item that was changed from a User Story to an Epic:
So maybe this key is set to false, and the work items migrated successfully but to another type (their original type before changing).
@RehabAbotalep - Already tried that and it does not bring back the desired results. It does not bring back all history etc. I think @MrHinsh already acknowledged as an issue.
Are you using Prompt or PAT?
I think this only works if you use PAT!
Are you using Prompt or PAT?
I think this only works if you use PAT!
I was using PAT.
You might need to debug in Visual Studio and see why its not doing it thing.
Its supposed to replace the Work Item Type in the revisions with whatever the latest revision is all the way down.
I'm seeing the same behavior in my testing. I'm using "SkipToFinalRevisedWorkItemType: true" to try and avoid the type change, but I'm limited to Prompt authentication (cannot get full access PATs) so I'm wondering if that's part of the issue.
@MrHinsh Am I out of luck on migrating type-changed WIs if I can't get a Full Access PAT?
There is a fix in the system that's supposed to fast forward to the latest wit.
I've had a few reports that it's not working so it looks like it needs some work.
Thanks for the quick update. I'll keep an eye on these threads.
Ive checked the code and the simple work around is as @RehabAbotalep described:
SkipToFinalRevisedWorkItemType: true
This will create the work item in its final type state and will work both for PAT and Promopt.
var skipToFinalRevisedWorkItemType = _config.SkipToFinalRevisedWorkItemType;
var finalDestType = revisionsToMigrate.Last().Type;
var targetType = revisionsToMigrate.First().Type;
if (targetType != finalDestType)
{
TraceWriteLine(LogEventLevel.Information, $"WorkItem has changed type at one of the revisions, from {targetType} to {finalDestType}");
}
if (skipToFinalRevisedWorkItemType && Engine.TypeDefinitionMaps.Items.ContainsKey(finalDestType))
{
finalDestType = Engine.TypeDefinitionMaps.Items[finalDestType].Map();
}
if (Engine.TypeDefinitionMaps.Items.ContainsKey(targetType))
{
targetType = Engine.TypeDefinitionMaps.Items[targetType].Map();
}
targetWorkItem = CreateWorkItem_Shell(Engine.Target.WorkItems.Project, sourceWorkItem, skipToFinalRevisedWorkItemType ? finalDestType : targetType);
Regardless of the setting, you should see "WorkItem has changed type at one of the revisions, from " in the log!
I would assume that if you don't have this set it will, as @RehabAbotalep shows in her screenshots, use the old type.
@MrHinsh I deleted the troublesome WIs and re-ran the migration with SkipToFinalRevisedWorkItemType but I'm still getting a failure, so there may be a different issue in my environment. The logs show a save failure with the stack trace error below..
[10:03:23 INF] [ Issue][Complete: 6/6][sid: 15248|Rev: 15][tid: null | System.IterationPath (Iteration Path) |
[10:03:23 ERR] System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.Services.WebApi.VssServiceResponseException: Page not found.
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.1.MoveNext() --- End of inner exception stack trace --- at System.Threading.Tasks.Task
1.GetResultCore(Boolean waitCompletionNotification)
at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List1 revisionsToMigrate, WorkItemData sourceWorkItem, WorkItemData targetWorkItem) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 628 ---> (Inner Exception #0) Microsoft.VisualStudio.Services.WebApi.VssServiceResponseException: Page not found. at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<HandleResponseAsync>d__53.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__51.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__47
1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.
As a workaround, just to get the items created, I can set ReplayRevisions to false but obviously I won't have the history attached.
I am also having trouble with migrating items that have changed type. I have tried updating to the latest version 14.0 as I was having the problem on 13.0. I have tried with SkipToFinalRevisedWorkItemType set to true and false but am receiving the same error as MSFTkyweis posted above.
I am bieng left with a work item created but without an name or any details attatched.
If I run the migration a second time and it does not prompt for access, I assume it has cached it, the I get the following error but again only on items when it is trying to migrate work items that have changed type.
I have checked and im pretty sure I have full access on the source and the target. So I dont know if this error might be a red herring or not.
System.AggregateException: One or more errors occurred. ---> Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: VS30063: You are not authorized to access https://dev.azure.com.
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__28
1.MoveNext()
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List
1 revisionsToMigrate, WorkItemData sourceWorkItem, WorkItemData targetWorkItem) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 631
---> (Inner Exception #0) Microsoft.VisualStudio.Services.Common.VssUnauthorizedException: VS30063: You are not authorized to access https://dev.azure.com.
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__28
1.MoveNext()<---
Discussed in https://github.com/nkdAgility/azure-devops-migration-tools/discussions/1573