Usuário relatou refresh constante na tela do conector 2C. O problema foi resolvido temporariamente após limpar os logs e refazer o login.
Foi identificado erro 401 (Não Autorizado) em um endpoint, possivelmente causado por perda de token, o que força nova tentativa de login.

Evidências:

• curl da chamada afetada

• Gravação da agenda de 05/11/2025 às 10h26

curl 'http://localhost:8880/api/v2/connection/metrics' \  -H 'Accept: application/json, text/plain, /' \  -H 'Accept-Language: pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7' \  -H 'Authorization: Bearer XXXXXXXXXXXXXXX' \  -H 'Connection: keep-alive' \  -H 'Content-Type: application/json' \  -H 'Referer: http://localhost:8880/ui/connection' \  -H 'Sec-Fetch-Dest: empty' \  -H 'Sec-Fetch-Mode: cors' \  -H 'Sec-Fetch-Site: same-origin' \  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36' \  -H 'sec-ch-ua: "Google Chrome";v="141", "Not?A_Brand";v="8", "Chromium";v="141"' \  -H 'sec-ch-ua-mobile: ?0' \  -H 'sec-ch-ua-platform: "Windows"'

Passos para simular:

• Fazer um novo login na mesma ORG (TOTVS)

• Fazer um logout na mesma org (TOTVS)

Esses dois eventos geram uma inativação de tokens anteriores e deixa o 2C com um token invalido.O esperado:

• 2C deve fazer o login através de um connectorID especifico do 2C, não do login da Carol (0a0829172fc2433c9aa26460c31b78f0). Vc consegue confirmar como é feito hoje?

• No caso do login ter perdido a validade (mesmo usando um connectorID especifico, o 2C deve forçar um novo login.

Eu desconfio que o problema esteja no contexto da Carol, que deve forçar todos os logins via SAML a assumir o mesmo connectorID, e faz com que o 2C seja prejudicado em login / logout em outras áreas da Carol. Eu teste em outra org e funciona OK, possivelmente pq o 2C informa o connectorID específico dele, garantindo ter uma sessão isolada.