Dear RWS team, dear community,

we are developing an application which uses the Trados Studio 2019 / 2021 API with Groupshare 2017 / 2020 TMs. Unfortunately, the Studio 2019 ( 15.2.8.3007 ) API does not renew its authentication token if our application keeps running for more than 12 hours. The GS 2017 ( GS: 14.2.60175.10 - SR1 CU10 ) TMService.log explicitly states:

2021-04-30 15:25:44.9247|OURGSSERVER|Warn|THREAD_ID:32|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Authentication failed: The message expired at 29.04.2021 03:41:24 and it is now 30.04.2021 15:25:44.
2021-04-30 15:25:44.9247|OURGSSERVER|Warn|THREAD_ID:32|TR_ID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|Unauthorized request

We could reproduce the error message when creating a bearer token manually from GS 2017 using Postman with the following commands: groupshareserver/authentication/api/1.0/login with access to ["ManagementRestApi", "ProjectServerRestApi", "TMServerRestApi"] and afterwards groupshareserver/api/tmservice/tms for testing the validity of the token. If we tested the second call during the next day, the log states that the token is invalid after 12 hours, see error message above.

The error lies within the Studio API, since we only communicate with the GS through the project automation API, see issue: https://community.sdl.com/developers-more/developers/language-developers/f/sdk_qa/34244/unexpected-exception-when-initializing-task-using-server-tms-on-groupshare-2017-server-failed-to-initialize-translation-engine-follows which is exactly the way the error occurs in the first place.

• Is there a possiblity to make the Studio API renew the token manually, like calling a non-editing endpoint?
• Is there another way of accessing TMs within a project, that does not fail after 12 hours?
• If not, is it possible to fix this issue of the Studio 2019 API?

Our assumption is that possibly not all objects are cleaned up correctly by the GC, since a restart of our application does reset the problem (until the next 12 hour timespan). On our side we end the API call with FileBasedProject.save(), dereferencing the object, and even a GC.collect() did not help. Somewhere in the API the bearer token still will be held.