Incidente: Função FCreate quando utilizada com um caminho do client, está retornando um handle sempre válido, mesmo quando a pasta não existe, causando erro depois.

Solução: Problema só ocorre no binário Onça, devido a uma melhoria no controle de arquivos para webapp/web-agent, faltava verificar se a pasta de destino existia antes de criar o arquivo.
Referente ao chamado: DTAPPSRV-8968

Incidente: Em uma GRID, ao pressionar seta para baixo para criar uma nova linha, a linha atual é "apagada"

Solução: Correção feita para tratar corretamente a criação de uma nova linha sem perder a anterior.
Referente ao chamado: DTAPPSRV-9073

Incidente: Ao imprimir e selecionar um diretório que não existe no client, o mesmo não está verificando isso e no final da geração do arquivo gera um error.log porque o diretório não existe.

Solução: Primeiro é verificado se foi possível criar o arquivo do lado do client, se negativo já retorna erro e o ADVPL consegue tratar corretamente a criação de diretório se for o caso.
Referente ao chamado: DTAPPSRV-9074

Incidente: Ao utilizar a função tFileDialog, usar o retorno diretamente na função CpyT2S não funciona.

Solução: Como a função tFileDialog joga o arquivo na pasta do usuário do webapp, foi necessário alterar a função CpyT2S para considerar essa pasta como sendo do lado do servidor para conseguir realizar a cópia.
Referente ao chamado: DTAPPSRV-9101

Incidente: Foi observada uma intermitência no encerramento dos processos durante uma compilação de fonte ou aplicação de patch que em certas situações gerava queda do Appserver.

Solução: Foi criada uma proteção na finalização dos recursos REST para evitar essa intermitência.
Referente ao chamado: DTAPPSRV-8734

Incidente: Ao aplicar um filtro com a expressão OR em uma tabela aberta via RDD SQLite, a navegação com DBSkip(-1) apresentava falha: a aplicação não conseguia identificar corretamente o BOF (begin of file) durante a emulação ISAM.

Solução: Fizemos um ajuste no AppServer para evitar a falha na identificação do BOF, o que trazia um falso entendimento de que a aplicação estava retrocedendo na navegação dos registros.
Referente ao chamado: DTAPPSRV-8930

Incidente: função GetUserInfoArray apresentando diferença de comportamento via linha de comando do AppServer. No array de retorno da função não estava vindo os dados de nome da máquina e do usuário logado, diferente de quando executado via Smartclient.

Solução: foram realizados ajustes na camada de criação de jobs.
Referente ao chamado: DTAPPSRV-8987

Incidente: Erro 404 ao acessar o Protheus via WebApp quando a chave App_Environment está ativa e a chave RootPath utiliza um caminho relativo. O erro ocorria devido a uma restrição que bloqueia o uso de ".." na URL. Como o caminho relativo incluía "..", a requisição era barrada.

Solução: Quando RootPath for configurado como relativo, ele passará a ser convertido internamente para um caminho absoluto.
Referente ao chamado: DTAPPSRV-9003

Incidente: Queda do AppServer durante o gerenciamento de licenças web. Uma exceção lançada pelo gerenciador de licenças, ao tentar adicionar novamente uma licença já marcada como em uso, não era tratada, ocasionando a queda do AppServer.

Solução: Adicionado tratamento para a possível exceção lançada pelo gerenciador de licenças, prevenindo a queda do AppServer.
Referente ao chamado: DTAPPSRV-9043

Incidente: Parâmetros nomeados não estavam funcionando ao chamar o construtor New.

Solução: Foi realizado o tratamento na linguagem TLPP para sanar esse débito técnico.
Referente ao chamado: DTAPPSRV-9044

Incidente: Inconsistência durante o debug multithread de APIs REST via VSCode que em determinadas situações ocasionava a queda do server REST.

Solução: Foi inserida uma proteção no código para evitar a inconsistência observada.
Referente ao chamado: DTAPPSRV-9061

Incidente: HTTPQuote apresenta falha enviando Content-Length=0 incorretamente na requisição HTTP DELETE.

Solução: Revisado a função HTTPQuote para tratar corretamente a requisição do tipo HTTP DELETE.
Referente ao chamado: DTAPPSRV-9099

Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp)
Referente ao chamado: DTAPPSRV-9110

Incidente: Inconsistências observáveis na integração com SQLite.

Solução: Atualizações realizadas nas APIs dos componentes envolvendo o SQLite
Referente ao chamado: DTAPPSRV-9112

Incidente: No momento de uso da autenticação via SAML é apresentada a mensagem de erro: Error with IDP metadata file: IDP metadata URI error: Couldn't resolve host name.

Solução: Implementação de correção na mensagem de erro e documentação de como proceder no caso da ocorrência do erro. Documentação: https://tdn.totvs.com/display/tec/SAML+-+Error+with+IDP+metadata+file
Referente ao chamado: DTAPPSRV-9119

Incidente: Broker Agent não estava fazendo scale-in na versão 24.3.0.11.

Solução: Correção no processo de Scale-in executado pelo Broker Agent.
Referente ao chamado: DTAPPSRV-9158

Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp)
Referente ao chamado: DTAPPSRV-9164

Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp)
Referente ao chamado: DTAPPSRV-9166

Proteção de uso de contextos na camada de comunicação para evitar falhas que resultavam na geração de arquivos de depuração (*.dmp)
Referente ao chamado: DTAPPSRV-9169

Incidente: Access Violation em serviço Rest ou Broker.

Solução: Foi realizado um tratamento interno para proteger o serviço, finalizando graciosamente a conexão afetada, porém mantendo as demais conexões com o fluxo esperado.
Referente ao chamado: DTAPPSRV-9176

Incidente: Access violation gerado em um json durante uma exceção tratável, especialmente se for json inline.

Solução: O servidor de aplicação fez o tratamento para que um comportamento inesperado do objeto json não gere uma inoperância do servidor.

Referente ao chamado: DTAPPSRV-9178

Incidente: Em um fonte PRW, declarar duas variáveis como char / character, e tentar somá-las , sendo que AMBAS as variáveis possuem valor nulo (NIL), causava o término anormal do Serviço do TOTVS Application Server, com a ocorrência crítica "Access Violation".

Correção: O comportamento do operador de soma tipado já considerava variáveis com conteúdo NIL como uma string em branco. Desse modo, a soma de duas variáveis tipadas como string com conteúdo NIL retornará uma string em branco.
Referente ao chamado: DTAPPSRV-9200

Incidente: Problemas durante aplicação de patch e desfragmentação do RPO.

Solução: Foi ajustado um tratamento de validação de duplicidade de recursos que estava mantendo o rpo aberto.
Referente ao chamado: DTAPPSRV-9229

Incidente: Inconsistência no comportamento do ErrorBlock ao tratar erros de utilização do método SET da classe tHashMap

Solução: Foi inserida uma correção no código para que erros envolvendo a utilização dos métodos SET, GET, DEL e LIST da classe tHashMap sejam tratados conforme esperado pelo ErrorBlock.
Referente ao chamado: DTAPPSRV-9244

Ocorrência: Mensagem "FATALSERVER Cannot update a constant string" gerada no console.log do Application Server, com uma pilha de chamadas interna indicando a chamada TOP_LITE_TCSetParam.

Correção: Foi realizado o tratamento adequado do parâmetro recebido na função TCSetParam (https://tdn.totvs.com/x/4bclE).
Referente ao chamado: DTAPPSRV-9259

Incidente: Configurar o protocolo máximo suportado pelo servidor REST, devido à restrição de comunicação com alguns servidores.

Solução: Criada a chave SSLMaxMethod para o REST, que aceita os mesmos valores da chave SSLMethod.
Referente ao chamado: DTAPPSRV-8008

Incidente: Implementar suporte ao protocolo IPv6 nos serviços portal multiprotocolo, REST 2.0

Solução: Criada a possibilidade de ativar o protocolo IPv6 nos serviços de REST 2.0 e portal multiprotocolo (MPP). Vide documentação: https://tdn.totvs.com/x/wwmeCQ
Referente ao chamado: DTAPPSRV-8102

Incidente: Se dois ou mais fontes definissem, via annotation, um endpoint Rest com a mesma URL, isso poderia causar uma subida parcial dos serviços de Rest. Por exemplo, um fonte x.tlpp definia @Get("/test/resource") e um fonte y.tlpp também poderia definir o mesmo @Get("/test/resource").

Solução: Foi realizado um tratamento em tempo de compilação, que sempre observa se alguma URL de Rest, definida via annotation, já existe. Se já existir, a compilação desse fonte causa erro, alertando sobre a duplicidade. Com isso, se no repositório já existir um endpoint @Get("/test/resource") e um novo fonte tentar definir o mesmo @Get("/test/resource"), isso causará erro de compilação.

Referente ao chamado: DTAPPSRV-8463

Solicitação: Existir na classe TXMLManager uma forma de retornar quantos elementos existem em um certo grupo.

Solução: Criado o método XPathElementCount, que retorna a quantidade de nós com o mesmo nome apontado por uma expressão XPath.
Referente ao chamado: DTAPPSRV-8723

Solicitação: Foi solicitado a criação de métodos na classe TXMLManager para navegação baseado numa expressão XPath.

Solução: Criado o metodo XPathSetPostion na classe TXMLManager, que posiciona o objeto de acordo com a expressão XPath.

Referente ao chamado: DTAPPSRV-8724

Solicitação: ocorrência de "efeito manada" se muitos usuários se conectassem ao mesmo tempo (num intervalo de 5 segundos ou pouco mais) no ERP via broker, causando sobrecarga de memória no servidor que estivesse mais disponível para balanceamento

Solução: foi adicionado um "peso" a cada nova conexão a um servidor, de modo que mesmo se muitos usuários se conectam "ao mesmo tempo" ao ERP via broker não ocorrem mais distorções no balanceamento.
Referente ao chamado: DTAPPSRV-8847

Solicitação: O arquivo de diagnostics.json não estava salvando as informações sobre o tipo da build utilizada.

Solução: Foi inserido no arquivo diagnostics.json as informações sobre o tipo da build utilizada (RELEASE, REL WITH DEBUG ou DEBUG).
Referente ao chamado: DTAPPSRV-9030

Solicitação: Demanda de autenticação através do protocolo LDAP.

Solução: Implementação da função LDAPUserValid para sistema operacional Windows.
Referente ao chamado: DTAPPSRV-9036

Solicitação: Visualizar informação de inicialização do Application Server secundário na tela de status do Broker.

Solução: Foi alterada a apresentação de dados da tela de status do Broker e foram incluídas as informações de horário em que o serviço foi ativado (uptime) e a informação do identificador do processo do serviço (pid) para facilitar na identificação de múltiplos serviços ativados no mesmo host físico.
Na mensagem de status json foram inseridas as informações de horário em que o serviço foi ativado (uptime) e a informação do identificador do processo do serviço (pid).
Referente ao chamado: DTAPPSRV-9078

Solicitação: Exibir data e hora na qual o serviço (Application Server) entrou em quarentena.

Solução: Foi alterada a apresentação de dados da tela de status do Broker e foi removida a informação de próximo horário de monitoria de serviço em quarenta e no lugar foi incluída uma coluna que informa o horário de início de detecção de falha do serviço ("horário de entrada em quarentena").
Na mensagem de status json foi mantida a informação de próximo horário de monitoria de serviço em quarenta (quarantine) e foi incluída a informação de horário de entrada em quarentena (quarantine_entry_time).
Referente ao chamado: DTAPPSRV-9079

Incidente: Usuários perdem conexão com ERP em caso de queda do Broker HTTP.

Solução: Implementada uma funcionalidade opcional no Broker HTTP, que em caso de queda reinicia automaticamente o broker, de modo que os usuários não perdem conexão com o ERP. Vai aparecer uma janelinha popup amarela de reconexão (nativa do Smartclient Webapp), mas rapidamente o browser se reconecta na nova instância de broker que foi iniciada, e o usuário pode voltar a trabalhar normalmente.
TDN: https://tdn.totvs.com.br/display/tec/Alta+Disponibilidade
Referente ao chamado: DTAPPSRV-9080

Incidente: A checagem em compilação para endpoints duplicados em Rest não contemplava ainda duplicidade nos seguintes casos:

Endpoints repetidos dentro do mesmo fonte

Até então, a gente olhava apenas entre fontes distintos.
Faltava olhar dentro do próprio fonte.

Endpoint vazio (duas formas de escrever a mesma coisa)

@Get("")
@Get("/")

Endpoints iguais, de escrita ligeiramente diferente (barra facultativa)

@Get("xpto")
@Get("/xpto")
@Get("xpto/")
@Get("/xpto/")

Solução: A checagem de Duplicidade de Endpoints Rest agora está mais coesa, levando a implementações de maior qualidade.
Referente ao chamado: DTAPPSRV-9091

Solicitação: Dificuldade de identificar rollback de transações nas aplicações do AppServer em AdvPL, principalmente quando a aplicação largou equivocadamente uma transação aberta, e é realizado um rollback implícito no final da thread.

Solução: Criado mecanismo de rastreio de transações, habilitado pela configuração TRACETRANSACTION no environment desejado no appserver.ini. Para maiores informações, consulte a documentação da configuração TRACETRANSACTION no TDN
Referente ao chamado: DTAPPSRV-9144

Solicitação: Incluir mais informações no nome do arquivo de dump gerado pelo AppServer, seja configurado como Broker ou como AppServer.

Solução: Padronizado o nome do arquivo de dump para PREFIX_VERSION_BUILDTYPE_YYYYMMDD_hhmmss_THREADID_PID, onde PREFIX pode ser "core" ou "broker" e BUILDTYPE pode ser "dbg", "relwithdbg", "rel".
Referente ao chamado: DTAPPSRV-9160

Solicitação: Após sinalizar a finalização do appserver, seja com control+c ( console ) ou stop ( service manager ), se ocorrer um access violation durante a parada do serviço, era gerado um core dump completo no disco, ocupando relevante espaço e dando a falsa impressão que o serviço estaria caindo enquanto estava em uso.

Solução: Para evitar isso, não será mais gerado core dump após o serviço ser finalizado. Caso ocorra um Access Violation durante a finalização do serviço, será apenas mostrando no log de console a mensagem "*** THREAD <nnnnnn> - CRASH DURING APPSERVER SHUTDOWN ***"
Referente ao chamado: DTAPPSRV-9172

Solicitação: Aplicações e rotinas AdvPL usando XMLPARSER e/ou XMLPARSERFILE, sem chamar a função DelClassintf() ao final da execução, geram aumento de memória da thread.

Solução: Criada a configuração TRACEXMLPARSER=1, para ser colocada no appserver.ini, no environment em uso, para rastrear a criação de objetos XML com as funções acima, e informar se esses objetos não foram limpos no final da aplicação. Para maiores detalhes, consulte no TDN a documentação da configuração TRACEXMLPARSER.
Referente ao chamado: DTAPPSRV-9184

Solicitação: Descontinuação do driver CTREE Server e CTREE BoundServer

Solução: Remoção das bibliotecas CTREE do pacote do Application Server. Detalhes em: https://tdn.totvs.com/x/BtwNOw
Referente ao chamado: DTAPPSRV-9222

Solicitação: As informações registradas em console com a configuração ServerMemoryInfo=1 eram mostradas em KB, com 3 dígitos decimais, induzindo a erros de leitura.

Solução: As informações passam a ser mostradas em MegaBytes (MB), com 2 dígitos decimais, para todos os contadores de memória.
Referente ao chamado: DTAPPSRV-9231

Ocorrência: O kernel UEK do Oracle Linux não é homologado/suportado pelo AppServer e pode causar diversos problemas, por exemplo, quedas, lentidão, entre outros.

Melhoria: Inserida validação do kernel no AppServer Linux para verificar se o kernel é UEK e impedir a inicialização com a mensagem de erro abaixo:

[ERROR][SERVER] [DEBUG] *** THE KERNEL VERSION (N.N.N-NNN.el8uek.x86_64) IS UEK AND IT IS NOT SUPPORTED, PLEASE REFER TO THE DOCUMENTATION OF SUPPORTED OPERATING SYSTEMS https://tdn.totvs.com/x/g4H7Gg

Referente ao chamado: DTAPPSRV-9251

Solicitação: Implementar mensagem de descontinuidade do CTREE SERVER e BOUND SERVER no uso das chaves CTREEMODE

Solução: No momento da leitura das chaves CTreeMode (Seção General) e as seções ctreeServer, ctreeMaster, será exibida mensagem de descontinuidade desta funcionalidade, conforme documentação: https://tdn.totvs.com/x/BtwNOw
Referente ao chamado: DTAPPSRV-9252

Solicitação: Remover a limitação do tamanho das listas retornadas pela TCGetInfo().

Solução: Fizemos um ajuste no DBAccess 24.1.1.0 (https://tdn.totvs.com/x/Qf4gO) e removemos o limitador de tamanho para os slots que retornam listas de dados, vide: https://tdn.totvs.com/x/r-VUE.
Referente ao chamado: DTAPPSRV-9253

Incidente: Implementar uma forma de indicar quais tipos de conexões a TCQuit deve encerrar

Solução: Fizemos uma mudança na TCQuit que agora pode receber um novo parâmetro numérico para determinar seu comportamento.

Ajuste na TCQuit... Agora ela pode receber uma parâmetro numérico para determinar o comportamento de desconexão das threads!

0 = encerra todas as conexões
1 = encerra conexões de dados, mas mantém as conexões de controle de numeração automática e lockbyname (default)

Essa implementação depende do uso do DBAccess 24.1.1.0 ou superior.
Referente ao chamado: DTAPPSRV-9254