You schedule a TM Export via the GroupShare website or the RestAPI.
You notice that sometimes exports remain in the Queued status and appear to never start.

At the time the export should have started, you find following message in the TMService logs:

Level : Error
Message : TranslationMemoryServiceAgent.Exception: DotNetOpenAuth.Messaging.Bindings.ExpiredMessageException: The message expired at 15/01/2018 02:18:29 and it is now 15/01/2018 02:19:02.
   at DotNetOpenAuth.OAuth2.AccessToken.EnsureValidMessage()
   at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary)
   at DotNetOpenAuth.Messaging.UriStyleMessageFormatter`1.DeserializeCore(T message, Byte[] data)
   at DotNetOpenAuth.Messaging.DataBagFormatterBase`1.Deserialize(T message, String value, IProtocolMessage containingMessage, String messagePartName)
   at DotNetOpenAuth.OAuth2.StandardAccessTokenAnalyzer.DeserializeAccessToken(IDirectedProtocolMessage message, String accessToken)
   at Sdl.Services.Common.Authentication.GroupShare.GroupShareAuthenticationProvider.CreateAuthenticationContext(String token)
   at Sdl.Services.Common.Authentication.GroupShare.GroupShareAuthenticationProvider.CreateMessageContext(Dictionary`2 messageMetadata)
   at Sdl.Services.Common.MessageQueue.Core.MessageQueueWorker.<OnMessageReceived>d__40.MoveNext(); Request ID: 1f53bc15-bdd7-4014-87bb-f38b48d0d560; Service ID: tm-service
Opcode : Info
Task : 65530
Version : 1
Payload : [ : DotNetOpenAuth.Messaging.Bindings.ExpiredMessageException: The message expired at 15/01/2018 02:18:29 and it is now 15/01/2018 02:19:02.
   at DotNetOpenAuth.OAuth2.AccessToken.EnsureValidMessage()
   at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary)
   at DotNetOpenAuth.Messaging.UriStyleMessageFormatter`1.DeserializeCore(T message, Byte[] data)
   at DotNetOpenAuth.Messaging.DataBagFormatterBase`1.Deserialize(T message, String value, IProtocolMessage containingMessage, String messagePartName)
   at DotNetOpenAuth.OAuth2.StandardAccessTokenAnalyzer.DeserializeAccessToken(IDirectedProtocolMessage message, String accessToken)
   at Sdl.Services.Common.Authentication.GroupShare.GroupShareAuthenticationProvider.CreateAuthenticationContext(String token)
   at Sdl.Services.Common.Authentication.GroupShare.GroupShareAuthenticationProvider.CreateMessageContext(Dictionary`2 messageMetadata)
   at Sdl.Services.Common.MessageQueue.Core.MessageQueueWorker.<OnMessageReceived>d__40.MoveNext()] [ : 1f53bc15-bdd7-4014-87bb-f38b48d0d560] [ : tm-service] 
EventName : ExceptionInfo
Timestamp : 2018-01-15T02:19:45.0202196Z

 

This issue was addressed with the CU09 for SDL Trados GroupShare 2017 SR1.
The details for the CU09 can be found in the article Cumulative Updates for SDL Trados GroupShare 2017 SR1.



Workaround: Re-Queue Export

As an immediate workaround, you can simple start the export again. (You may want to delete the stuck background task.)

 

Workaround: Queue exports with sufficient time until expiry

When scheduling the export, ensure that sufficient time is left until the login/bearer token expires (it is valid for 12 hours).
When scheduling the export via the website, you can follow these steps:

1. Log out of the website
2. Log into the website again
3. Schedule the export.

This issue can occur when the export is scheduled with a bearer token ("login") that expires in the time between the export is scheduled and the export is started.
Note: In SDL Trados GroupShare 2017 SR1 (14.2.7902.0), the same situation results in the export failing instead.