UGS sync error: is opened at a later revision

For the sake of long term improvement, I wanted to report it was possible to encounter this error. I didn’t implement a fix locally since this is relatively rare but in case you want to address it.

EpicGames.Perforce.PerforceException: Expected record of type ‘SyncRecord’, got info: //project/main/Engine/Source/Programs/UnrealGameSync/UnrealGameSyncShared/WorkspaceUpdate.cs#20 - is opened at a later revision - not changed

at EpicGames.Perforce.PerforceResponse`1.get_Data() in D:\dev\h\main\Engine\Source\Programs\Shared\EpicGames.Perforce\PerforceResponse.cs:line 145

at UnrealGameSync.WorkspaceUpdate.SyncFileRevisions(IPerforceConnection perforce, WorkspaceUpdateContext context, Queue`1 syncCommandLists, HashSet`1 remainingDepotPaths, ProgressValue progress, ILogger logger, CancellationToken cancellationToken) in D:\dev\h\main\Engine\Source\Programs\UnrealGameSync\UnrealGameSyncShared\WorkspaceUpdate.cs:line 1660

at UnrealGameSync.WorkspaceUpdate.ExecuteAsync(IPerforceSettings perforceSettings, ProjectInfo project, WorkspaceStateWrapper stateMgr, ILogger logger, CancellationToken cancellationToken) in D:\dev\h\main\Engine\Source\Programs\UnrealGameSync\UnrealGameSyncShared\WorkspaceUpdate.cs:line 725

at UnrealGameSync.Workspace.UpdateWorkspaceMini(WorkspaceUpdate update, Task prevUpdateTask, CancellationToken cancellationToken) in D:\dev\h\main\Engine\Source\Programs\UnrealGameSync\UnrealGameSync\Workspace.cs:line 194

Steps to Reproduce
To reproduce this issue, one way is to sync backwards in UGS while having a file opened at a later revision (as per the error).

I possibly posted it a bit quickly and after looking at some changes I was doing in WorkspaceUpdate.cs, I realize this exception is just deferred until I actually try to access the SyncRecord, so in a sense, it is my code that is triggering it / revealing it. I’ll check if I have a way to type check each record before accessing it. Regardless, this might be useful feedback so I’ll leave my post but I don’t really expect a response. Thanks!

Maybe one small suggestion would be to have an easier way to check the internal data type is as expected. Current workaround consists of checking if .Info and .Error both return null

Small accessor such as

public T? TryGetData()

{

return InternalData as T;

}

could be sweet

cheers!

Hi,

Sorry for the delayed answer on this one. We have a shortage of UGS developers at the moment and I’m going through UGS tickets that were left unattended (even if you didn’t expect an answer). I see that you were able to identify and solve your problem, so I’ll just close the ticket. I’ll not log your small suggestion to JIRA, since it is minor improvement, it will be backlogged right away and it will rot there until the management does a pass and mass closes all tickets that are too old.

Regards,

Patrick