Smart Client web debug perde a conexão

[luisalbertovieira]

Describe the bug

Estou executando o smart client web debug o sistema inicia a conexão pelo modo debug mas depois em momentos alternados
perde a conexão, não finaliza o debug e alterna a conexão como se estive entrando sem o modo debug

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS/Architecture: [e.g. Windows 64 bits]

Appserver (please complete the following information):
TOTVS Distribuição e Logística (TOTVS)
Build: 7.00.240223P-20241010 - 64 bits
Versão da lib: 20250113
Release do RPO: 12.1.2410
Ambiente: Desenv_luis
Arquivos locais: ctree
Top DataBase: MSSQL
HardLock: 2014

2025-02-05_16h48_06.mp4

Módulo: FAT

[lwtnb-wrk]

@luisalbertovieira Voce esta depurando direto no SIGAFAT ou usando o SIGAMDI?

Veja em https://github.com/totvs/tds-vscode/blob/master/TROUBLESHOOTING.md#gerando-logs como gerar e nos envie o DAP.log para analises.

[lwtnb-wrk]

@luisalbertovieira Achei que era apenas um printscreen mas ao ver o video, vi que usou o SIGAFAT

Aparentemente a depuracao inicia, mas nao para em nenhum breakpoint e finaliza. Sempre que finaliza ele volta para tela padrao do webapp.

De qualquer forma nos envie o DAP.log que analisaremos com mais detalhes.

[lwtnb-wrk]

@luisalbertovieira Já adiantando, tente também excluir todos os breakpoints e adiciona-los novamente.

Outro fator importante é ter certeza que o o fonte que esta sendo depurado é o mesmo que esta compilado no RPO, confirme a data de compilação pelo Inspetor de Objetos.

[luisalbertovieira]

console_appserver_debug.log.txt
boa tarde segue o log do debug
O programa esta compilado com a ultima alteração

[lwtnb-wrk]

@luisalbertovieira O log que me referia é o que o tds-vscode gera, veja em https://github.com/totvs/tds-vscode/blob/master/TROUBLESHOOTING.md#gerando-logs como gerar o DAP.log e nos envie esse log.

[luisalbertovieira]

Bom dia
Segue o arquivo DAP.log

dap.log

[lwtnb-wrk]

@luisalbertovieira Pelos DAP.log nao vejo nenhuma ocorrencia anormal.
A depuracao inicia sem problemas, manda as informacoes de breakpoints para o AppServer e fica aguardando... Depois de algum tempo recebe um comando para finalizar a depuração.
Se foi a mesma coisa que voce fez no video original, pode ser alguma rotina na inicializacao do modulo que pode ter causado um erro no AppServer e encerrado a depuracao.
Experimente pegar um ambiente novo e/ou inicie esse webapp sem ser em uma depuração para ver ocorre algum erro, pois não parece ser nada do lado do tds-vscode.

[brodao2]

@luisalbertovieira

Já conseguiu depurar alguma vez nesse servidor/ambiente?

Certifique-se que esta se conectando a um servidor secundário ou "stand-alone" e que seu ambiente é de desenvolvimento (pode ser feito com a equipe do TCloud).
O TDS-VSCode só compila e depura em servidores secundários/"stand-alone" e ambientes configurados especificamente para isso.

[luisalbertovieira]

Bom dia
Esta entrando normal via webapp e não cai

Estamos acessando o ambiente stand-alone através do serviço de debug no tcloud

[brodao2]

@luisalbertovieira

Você tem como me enviar o INI desse servidor. Se não quiser anexar ao chamado, manda pro meu e-mail ([email protected]), por favor.

[luisalbertovieira]

boa tarde. Envie por email
Obrigado

[luisalbertovieira]

Complementando uma informação esse servidor de testes foi migrado agora para o release 2410 e é a primeira vez que estamos debugando via web.

[brodao2]

DESCONSIDERE ESSE COMENTÁRIO

Você esta se conectando ao servidor https://oup141214.protheus.cloudtotvs.com.br:1963
e pelo INI que mandou, é a porta 7600.

Verifique a propriedade "smartclientUrl" na definição do depurador Web e certifique-se também que a conexão (servidor/ambiente) esta sendo feita na mesma porta e tem que ser o mesmo a ser utilizado no "smartClientURL".

[lwtnb-wrk]

@luisalbertovieira Outros devs podem estar usando esse servidor ao mesmo tempo que voce? Vi que tem diversos environments cadastrados para um monte de devs nesse servidor...
O que pode estar ocorrendo tambem, seria uma concorrencia entre threads de varias pessoas acessando esse ambiente concorrentemente.
Confirme que nao tem mais ninguem usando esse servidor quando estiver depurando nele.

Quanto a questao da porta levantada pelo @brodao2 , nao acho que seja o problema pois se nao me engano o TCloud tem um proxy reverso na entrada e redireciona para a porta interna...

[luisalbertovieira]

No momento só eu estou utilizando. O ambiente ainda não foi liberado para usuários ou outros devs

[luisalbertovieira]

Testei com o projeto localizado no drive C: ao inves do onedrive e apresentou o mesmo problema

[lwtnb-wrk]

@luisalbertovieira Pode testar se conectando no environment "ANALISTAS_DEV" ao inves do "DESENV_LUIS" para ver se muda o comportamento?

[luisalbertovieira]

Alan, fiz alguns teste
-Executando pela porta 7600 dá erro de conexão . Voltei para a porta 1963
-Coloquei o projeto no drive C: fora do onedrive (continuou apresentando erro)

Aparentemente há algum problema com os pontos de parada na rotina
Executei sem nenhum ponto de parada e a rotina processou até o fim
Executei com um ponto de parada no começo do programa e ele desconectou.
Segue os dois DAP com e sem ponto de parada

dap_sem_ponto_de_parada.log

dap_com_ponto_de_parada.log

[luisalbertovieira]

outro detalhe, usando o projeto no drive C: ao inves do onedrive parece que ficou mais estavel. Pelo onedrive as vezes desconectava antes de abrir a rotina customizada, pelo drive C: isso ainda não ocorreu. Só cai quando tem os pontos de parada

[bryanbs-grupofarroupilha]

Também estamos com o mesmo problema. Iniciamos o Debug e após um tempo de uso a conexão cai.
No nosso caso o Protheus é on premise.

totvs.tds-vscode - 2.0.11
Protheus 2410

[lwtnb-wrk]

@luisalbertovieira Grato pelas informações e logs adicionais.

Pelo que no log com pontos de paradas, a depuração parou na linha 40 do fonte RFATR32.PRW como esperado e você deu um F5 (continue) e ele processou ate o final, pois não havia mais nenhum ponto de parada, ou seja, aparentemente depurou como deveria.

[lwtnb-wrk]

@bryanfarroupilha

Também estamos com o mesmo problema. Iniciamos o Debug e após um tempo de uso a conexão cai. No nosso caso o Protheus é on premise.

totvs.tds-vscode - 2.0.11 Protheus 2410

Qual a build exata do AppServer? Veja em https://github.com/totvs/tds-vscode/blob/master/TROUBLESHOOTING.md#gerando-logs como gerar e nos envie o DAP.log para analises.

[luisalbertovieira]

Alan, na verdade quando a rotina para no ponto de entrada na linha 40, ele reinicia a conexão no browse e não finaliza o processamento.
Segue o video

2025-02-06_16h00_29.mp4

E também voltou a ocorrer de perder a conexão logo na entrada no protheus não chegando a chamar a rotina. Segue o video

2025-02-06_15h54_45.mp4

[brodao2]

@luisalbertovieira

Pode nos enviar o log de console (completo) do Protheus no qual se conecta?

[luisalbertovieira]

Segue o log de do protheus.

console_appserver_debug.log (1).txt
dbconsole.log.txt

[lwtnb-wrk]

@luisalbertovieira Veja a possibilidade de atualizar o AppServer e/ou webapp para a ultima versao do Portal.

Não vejo nada de errado nos logs que possa causar esse problema.

Aparentemente ocorre um erro no Appserver e/ou webapp e por isso a depuração é encerrada e o webapp reiniciado.

[luisalbertovieira]

ok. Soliciitei a atualização no Tcloud. Assim que atualizar valido novamente.
Obrigado

[luisalbertovieira]

Boa tarde.. foi aplicada atualização do appserver e webapp, porém continuou com o mesmo comportamento, perdendo a conexão durante a execução no ponto de parada

[lwtnb-wrk]

@luisalbertovieira Voce teria acesso a algum outro fonte para testar a depuracao? Se for de outro modulo, melhor ainda para isolar o comportamento. Alem disso, chegou a requisitar a atualizacao do RPO (LIB) tambem ou apenas dos binarios?

Minha suspeita ainda recai em algum processamento especifico desta rotina que derruba o webapp/appserver e por isso a depuracao tambem cai e reinicia a conexao webapp.

Para auxiliar, veja se consegue ligar estes logs adicionais do webapp, adicionando essas chaves na secao [webapp] do appserver.ini para ver se gera mais informacoes sobre a queda:

[WEBAPP]
Port=
VaderLogLevel=255
VaderLogFiles=10
VaderLogSize=1048576
log_messages=1

[bryanbs-grupofarroupilha]

console.log

@lwtnb-wrk
Também fiz um teste em debug ativando:
[WEBAPP]
Port=
VaderLogLevel=255
VaderLogFiles=10
VaderLogSize=1048576
log_messages=1

Anexei o console.log do meu serviço.

Outros LOGs que gerou

webapp.log
webapp_250210_091450.txt
webapp_250210_091621.txt
diagnostics.json

[lwtnb-wrk]

@bryanfarroupilha Confirma com o TCloud se atualizaram o ambiente correto pois no console.log ainda aparece:

2025-02-10T09:05:32.137000-03:00 10024|*** TOTVS S/A ***
*** www.totvs.com.br ***

• TOTVS - Build 7.00.240223P - Oct 10 2024 - 09:12:58
• Build: 64 bits
• SVN Revision: 42847
• Build Version: 24.3.0.1

O webapp parece correto.

[luisalbertovieira]

Bom dia . Abaixo os dados da build

Efetuei o processamento do debug duas vezes, uma com ponto de parada onde perdeu a conexão e outra sem o ponto de parada onde o debug executa a rotina até o fim e não perde a conexão. Segue os logs e o Dap correspondentes.
Quando perde a conexão no debug o sistema apresenta também a tela abaixo

E solicita uma nova conexão sem o debug

console_appserver_debug_com_ponto_parada.log.txt
console_appserver_debug_sem_ponto_parada.log.txt
dap_com_ponto_parada.log
dap_sem_ponto_parada.log

[lwtnb-wrk]

@luisalbertovieira O log "dap_com_ponto_parada.log" trouxe um informação interessante, pois a ultima linha indica o inicio da execução de um "evaluate", mas não o termino dessa execução.
Isso esta ocorrendo no fonte "ZFATF13.PRW" ao parar na linha 1651, durante o evaluate de "_lNovo", mas não faz muito sentido dar erro neste evaluate simples.
Poderia repetir esse teste com o ponto de parada e reenviar o dap.log para confirmar?

[luisalbertovieira]

Boa tarde,
Criei um programa mais simples (TESTDEBUG.PRW) apenas para dar um alert de uma variavel na tela e criei também um projeto apenas com esse fonte na pasta para simplificar a análise
O Debug teve o mesmo comportamento, sem o ponto de parada executou até o fim e apresentou a mensagem na tela.
Com o ponto de parada na linha 9 perdeu a conexão e não finalizou o programa

console_appserver_debug.log (3).txt

dap.log

TESTDEBUG.txt

[brodao2]

@luisalbertovieira

Revendo o histórico do chamado, reparei que há definições no "watch". Se ainda os tiver, remova por favor.

Reparei tb que tem dois icones de outras extensões? Que extensões são essas?
Assim posso verificar se há alguma incompatibilidade.

[lwtnb-wrk]

@luisalbertovieira Neste ultimo "console.log" na lista de threads apareceram outras conexões [### TOTVS Developer Studio ###] indicando que possivelmente outro usuario esta logado neste appserver e pode estar interferindo nas depuracoes.

----------- Detailed Thread List ----------
[ 6916][ 644.930 Kb] LSPULSE THIS FWLSMANAGERPULSE ANALISTAS_DEV Mon Feb 10 09:26:45 2025 05:12:37 20613 1 []
[ 2500][ 1189.859 Kb] Luis Alberto Vieira MRC-52J6CD2 Mon Feb 10 14:38:28 2025 00:00:54 5 0 [### TOTVS Developer Studio ###]
[ 8004][ 47933.539 Kb] User MRC-20DNBS2 DESENVOLVIMENTO_CSC Mon Feb 10 09:53:36 2025 04:45:46 325 0 [### TOTVS Developer Studio ###]
[ 5116][ 10635.641 Kb] User MRC-20DNBS2 DESENVOLVIMENTO_CSC Mon Feb 10 09:53:00 2025 04:46:22 310 0 [### TOTVS Developer Studio ###]
[ 3936][ 69719.703 Kb] Luis Alberto Vieira MRC-52J6CD2 SIGAEST DESENV_LUIS Mon Feb 10 14:38:50 2025 00:00:32 0 37194 7476 [Emp :01/01Logado:lvieira SIGAEST obj:Janela Principal]
[ 3124][ 1189.977 Kb] Luis Alberto Vieira MRC-52J6CD2 Mon Feb 10 14:38:47 2025 00:00:35 3 0 [### TOTVS Developer Studio ###]

[ TOTAL][ 131313.648 Kb][Num: 6 ]

Tem certeza que ninguem mais esta usando esse appserver alem de voce?

[brodao2]

@luisalbertovieira

Experimenta ativar "enableMultiThread" na definição do depurador.

[luisalbertovieira]

@luisalbertovieira

Revendo o histórico do chamado, reparei que há definições no "watch". Se ainda os tiver, remova por favor.

Reparei tb que tem dois icones de outras extensões? Que extensões são essas? Assim posso verificar se há alguma incompatibilidade.

Boa tarde.. nesse ultimo teste que enviei, não há definiçoes no "watch" Eu não identifiquei esses dois icones de outras extensões. Aonde você visualizou eles?

[brodao2]

@luisalbertovieira

" Eu não identifiquei esses dois ícones de outras extensões. Aonde você visualizou eles?"

Eu vi na 1a msg desse chamado. Com o vídeo parado mesmo. Repare logo abaixo do logo da TOTVS.

[brodao2]

@luisalbertovieira

Experimenta ativar "enableMultiThread" na definição do depurador.

Tentou rodar o debug com essa chave ativa?

[luisalbertovieira]

Bom dia
Estamos fazendo uma bateria de testes aqui ainda
A principio ativando o "enableMultiThread" o debug funcionou, apesar de as vezes a conexão com o debug cair.
Fiz testes inclusive com outros usuários conectados no mesmo ambiente que estou utilizando e também funcionou
Testei sem o "enableMultiThread" e também passou a funcionar então não sei se foi essa alteração que resolveu
Porém, outro consultor que trabalha no mesmo projeto aplicou as mesmas alterações que apliquei e pra ele não está funcionando, sempre cai a conexão no ponto de parada
Resumo das ações aplicadas até o momento
-Projeto no drive C:\ ao inves do onedrive
-enablemultithread = true
-lib e appserver atualizado
-Webapp atualizado
-Depurar pelo SIGAFAT ou SIGAEST ao inves do SIGAMDI
-Confirmar se não tem nenhum usuario conectado

[luisalbertovieira]

Bom dia
O outro consultor de fato ainda não conseguiu.
Abrimos um novo chamado ou continuamos interagindo nesse mesmo?

[lwtnb-wrk]

@luisalbertovieira Grato pelos testes e retorno.
Então apenas para conhecimento, a depuração ocorre sempre em uma thread especifica que é a indicada pelo DEBUGID na url do webapp.
Ao ativar o modo de depuração o AppServer, por padrão, passa a monitorar essa thread e ao atingir condições de parada envia sinais ao tds-vscode e congela as threads. E é por isso que recomendamos ter um ambiente separado e controlado para a depuração. Quaisquer outros usuários conectados nesse ambiente serão impactados pela depuração.
Ao habilitar a opção "enablemultithread" o AppServer passa a monitorar todas as threads e geralmente usamos para depurar JOBS/WS, então não recomendamos usar caso não necessite.
É por isso também que recomendamos a depuração vai módulo diretamente pois o SIGAMDI e SIGAADV abrem múltiplas threads e já causam problemas por si só.

[lwtnb-wrk]

@luisalbertovieira Podemos continuar aqui sim, apenas nos envie mais logs.
Inclusive se puder, nos envie um DAP.log de uma depuração no seu ambiente que passou a funcionar para avaliarmos e ver se percebemos alguma diferença.

[luisalbertovieira]

Boa tarde
Obrigado pela explicação
Segue o DAP.log e console também executado sem erro.
Coloquei 3 pontos de parada na rotina que passou por todos e finalizou a execução

console_appserver_debug.log (6).txt

dap.log

[lwtnb-wrk]

@luisalbertovieira Nos envie logs do outro consultor que ainda esta tendo problemas.

[luisalbertovieira]

Segue o log do outro consultor. Ele fez um teste no repositorio dele e no meu também. Os dois apresentaram erro

console_appserver_debug_marcelo.log.txt
dap_marcelo.log

[lwtnb-wrk]

@luisalbertovieira O console.log nao continha a parte referente ao dap.log, pois nao tinha nenhuma referencia a thread de debug...
O console.log as vezes demora um pouco (buffer) para logar as mensagens.
Entao apos executar a depuracao, espere um pouco para pegar o console.log, pois se pegar muito cedo pode nao ter tido tempo de gravar os logs.
Se puder repetir o teste com o outro consultor, no envie os novos logs.

[luisalbertovieira]

Boa tarde
Segue o console e o dap atualizados e gerados no mesmo momento

dap 2.log
console_appserver_debug.log (7).txt

[lwtnb-wrk]

@luisalbertovieira Estes logs também não apresentaram nenhum problema e/ou erro. Aparentemente os processos estão seguindo até o final quando terminam sem erros aparentes e depois retornam a tela inicial de webapp com era esperado.