Agregado2
O atendimento que espera decisão volta a pedir passagem
Quando o assistente precisa que alguém da equipe destrave algo, ele abre um atendimento e continua conversando com o cliente. Se ninguém abre esse atendimento, ele ficava lá — e nada avisava. O cliente esperava, e a única evidência era uma linha numa tela que talvez ninguém tivesse aberto naquele dia.
Agora, passado um dia sem ninguém encostar, aparece um aviso na Central (e no sino) dizendo que um atendimento espera decisão. Clicar no aviso abre o atendimento certo, não a lista.
O aviso não se repete enquanto não for resolvido, e o sistema cobra no máximo três vezes: alarme que nunca cala ensina a ignorar o alarme certo.
Dá para fechar um dia da agenda
Feriado, férias, viagem: agora existe onde dizer "neste dia não atendo". Fica em Configurações › Agenda, e a partir dali o sistema deixa de oferecer horários naquele dia — para você, para o cliente que consulta e para o assistente de IA.
O que já estava marcado continua marcado. Fechar o dia impede o novo; o que fazer com quem já tinha horário é decisão sua, compromisso por compromisso.
Até agora a única saída era marcar um compromisso falso de dia inteiro, que suja a agenda, conta como atendimento e aparece no histórico do cliente.
Cambiado1
Criar resposta rápida duas vezes com a mesma chave não cria duas
Quem chama a API pode repetir com segurança uma criação que não chegou a receber resposta: enviando o cabeçalho Idempotency-Key num POST /api/v1/message-templates, a segunda chamada com o mesmo conteúdo devolve a resposta da primeira em vez de criar outra resposta rápida, e a mesma chave com conteúdo diferente é recusada com 409. Nada muda na tela e não há nada a fazer na VPS: a garantia alcança os clientes que mandam a chave, que o cliente HTTP do próprio produto já injeta em toda mutation.
A corrida entre duas chamadas simultâneas com a mesma chave continua aberta — a tabela de recibos só sabe guardar resultado terminal, então fechar essa janela exige mudança de schema, levada como pergunta na issue #778.
Corregido28
O agente para de se apresentar como assistente virtual contra as instruções dele
O texto de base que o sistema coloca antes das instruções de todo agente mandava ele "se apresentar como assistente virtual" na primeira interação. Quem escrevia na tela do agente um nome próprio e pedia para não usar esse termo via o agente repetir "assistente virtual" mesmo assim, porque as duas ordens chegavam juntas. A apresentação agora fica com as instruções do agente; continua valendo que ele nunca afirma ser humano e responde com honestidade se perguntarem.
Vale para instalações novas. Em instalação existente o texto de base já gravado no banco não é trocado sozinho. Crédito: @rafaelbatistazz.
A proteção da agenda passa a valer para o agente que só consulta horários
O produto tem uma garantia dura: o agente não pode dizer "vou verificar o horário e te aviso" — nem "está confirmado" — sem ter consultado a agenda de fato. Ela estava armada só para agentes que podem MARCAR sozinhos.
Quem configura o agente para apenas consultar, deixando a confirmação com uma pessoa da equipe — o arranjo normal de clínica, salão e consultório —, tinha um agente sem essa proteção e sem as instruções de agenda. Ele prometia verificar e não verificava, e nada no sistema acusava.
Agora a proteção vale para qualquer agente com ferramenta de agenda, e o texto que corrige o agente nomeia só as ferramentas que ele realmente tem: mandar "chame crm_book_appointment" para quem não a tem fazia o modelo tentar uma ferramenta inexistente.
Nada muda para quem já tinha o agente marcando sozinho.
O campo de busca do Inbox passa a dizer o que realmente procura
O campo de busca do Inbox dizia "Buscar por nome, telefone ou mensagem", mas procura apenas na ÚLTIMA mensagem de cada conversa — não no histórico. Quem buscava uma frase dita no meio do atendimento não encontrava nada, sem qualquer aviso de que aquela parte da conversa estava fora do alcance.
O texto do campo agora diz "última mensagem". Nada mudou no que a busca encontra: ela continua achando por nome, por telefone (em qualquer formato) e pela última mensagem. O que mudou é que a tela parou de prometer o que não entrega.
Buscar dentro do histórico inteiro está no plano, como melhoria à parte.
Crédito: @paulolimajr77
A busca do Inbox acha o contato mesmo quando o nome é digitado diferente
Procurar um contato pelo nome exigia digitar exatamente como estava gravado. Num contato salvo como "Paulo Lima Jr", buscar "Paulo Jr" não achava nada — e "Paulo Lima", com dois espaços por engano, também não. Só achava quem digitasse o nome inteiro e na ordem certa.
Agora espaço, vírgula e ponto e vírgula são tratados igual: "Paulo Jr", "Paulo Lima" e "Paulo, Jr" encontram o mesmo contato. Buscar pelo sobrenome primeiro ("Lima Paulo") continua não achando — isso é uma mudança maior, para outra versão.
A busca por telefone não mudou: continua achando com ou sem DDD, com ou sem pontuação, e pelos últimos dígitos.
Você não precisa fazer nada para adotar. Crédito: @paulolimajr77
O cabeçalho para de se sobrepor no celular
Em telas estreitas, o nome da organização ficava por baixo do campo de busca, e a busca por cima do sino de avisos. Quanto mais longo o nome, pior.
No celular o seletor de organização passa a mostrar só o ícone da loja. O nome completo continua a um toque, dentro do menu que ele já abre, e quem usa leitor de tela continua ouvindo o nome normalmente.
No computador nada muda.
Botões que dependem do banco param de travar a instalação inteira quando o atendimento está ocupado
Medido numa instalação real. O botão Enviar link ao cliente (do Google Meet) parecia não funcionar: aparecia "Erro inesperado. Tente novamente.", sem nenhuma pista, e clicar de novo não resolvia.
O que acontecia por baixo: a operação pede uma reserva no banco para não atropelar um atendimento em curso — e essa espera não tinha prazo. O navegador desistia em 10 segundos e mostrava o erro, mas o pedido continuava vivo no banco, segurando a fila. Como o botão voltava a funcionar, cada clique empilhava mais um pedido atrás do anterior.
Com dez pedidos empilhados, o banco de dados da instalação foi a 357% de processador — e nada mais respondia bem, inclusive telas que não tinham nada a ver com aquilo.
Agora toda chamada da aplicação desiste de esperar em 4 segundos e diz o motivo: "Este atendimento está ocupado neste instante. Aguarde alguns segundos e tente de novo." Nada fica pendurado, e a frase diz o que fazer.
O conserto vale para toda a aplicação, não só para esse botão: sete operações tinham a mesma forma, incluindo Aprovar e enviar (da sugestão de resposta), mesclar contatos, conectar canal e anonimizar contato da LGPD. O trabalho de fundo (filas e agendadores) continua podendo esperar o tempo que precisar — lá não há ninguém olhando a tela.
Nada muda para quem opera: sem passo manual, sem mexer em configuração.
Modelo padrão em IA → Provedores volta a ser salvável quando o catálogo do provedor ainda não sincronizou
O catálogo que alimenta o combo de modelo da tela IA → Provedores nasce de uma sincronização que só alguns provedores já têm semeada na instalação: quem escolhia um provedor cujo catálogo ainda não tinha sido baixado encontrava a lista vazia. Combo vazio, nada para escolher, e o botão de gravar o modelo padrão desabilitado — a tela existia justamente para configurar essa escolha, mas não oferecia nenhum caminho para fazê-lo, e não dizia por quê.
Agora, quando não há nenhum modelo conhecido para o provedor selecionado, o campo deixa de ser uma lista e passa a aceitar o identificador digitado, com uma nota explicando que a lista completa aparece sozinha depois da primeira sincronização. A gravação avisa que não deu para conferir o identificador contra o catálogo, em vez de dizer apenas que salvou: com o catálogo presente, um nome de modelo errado continua sendo recusado como antes.
Para quem opera uma VPS, nada muda: é conserto de tela, sem comando novo, sem variável nova e sem migração. Ninguém precisa fazer nada ao atualizar.
Os números das abas do Inbox passam a respeitar os filtros, e "Fechadas" ganha número
Os números ao lado das abas do Inbox ignoravam os filtros ligados na barra. Com "Não lidos" marcado, a lista podia mostrar nenhuma conversa enquanto a aba continuava estampando o total — mandando o atendente procurar um trabalho que não estava lá.
Agora as contagens aplicam os mesmos filtros que a lista: etiqueta, número de WhatsApp e não lidos. E a aba "Fechadas", que não tinha número nenhum, passa a ter.
A busca continua fora da conta: sob busca, o número da aba pode ficar maior que a lista. Contar a busca exigiria uma segunda maneira de procurar, e duas maneiras acabam discordando uma da outra.
Você não precisa fazer nada para adotar. Crédito: @paulolimajr77
Importação de contatos contabiliza repetições sem perder linhas válidas
Ao importar contatos por CSV, cada linha repetida agora aparece no total de duplicados do relatório. Uma linha rejeitada na validação ou na gravação não impede a importação de outra linha válida com o mesmo telefone ou e-mail. Se uma linha é pulada por ter um e-mail já cadastrado, seu telefone ainda não gravado continua disponível para as linhas seguintes. Crédito: @Tong-bit-art.
Credencial ainda não configurada deixa de derrubar a leitura
Toda credencial que ainda não foi preenchida — o segredo de webhook de uma sessão nova, por exemplo — era gravada como um byte de enfeite só para satisfazer a coluna. E o CRM, ao ler qualquer credencial, tentava decifrar esse byte como se fosse uma cifra de verdade: a leitura estourava toda vez, no mesmo registro, sem parar.
O efeito prático não estava na tela — quem lê uma credencial já tratava o erro como "não configurada". Estava no log, que enchia de erro permanente e indistinguível de uma chave mestra trocada, que é o único caso em que esse erro diz a verdade. Agora a leitura só tenta decifrar o que pode ser uma cifra: valor ausente, curto demais ou sem cara de pacote devolve "não configurada". Cifra de verdade que não abre continua aparecendo.
Você não precisa fazer nada para adotar: aplicar a atualização basta, e as credenciais já gravadas seguem onde estão.
Quem cria uma organização para outra pessoa sai dela quando essa pessoa assume
Ao criar uma organização pelo painel de plataforma, quem cria entra nela como administrador. Isso é necessário: sem ninguém dentro, a organização nasceria inacessível e nem daria para configurá-la antes de entregar.
O que faltava era a saída. Nada nunca tirava o criador de lá — a aba "Equipe" do painel de plataforma está desativada, a tela da organização recusa que alguém revogue o próprio acesso, e a jornada de convite não sabia da existência do criador.
Na prática, quem instala o sistema para clientes ficava dentro da empresa de cada um deles, para sempre. O cliente abria Equipe › Membros e encontrava o e-mail pessoal de quem instalou listado como se fosse um colega da equipe: ocupando uma vaga, aparecendo como responsável possível na Agenda, e podendo ser removido por ele — enquanto quem estava lá não tinha como sair.
Agora, quando a organização é criada para outra pessoa, o vínculo de quem cria nasce marcado como provisório. Ele existe só para a empresa não nascer vazia, e sai sozinho no momento em que a entrega se completa: quando o dono aceita o convite. Até lá o criador continua dentro, então a organização nunca fica sem ninguém.
Quem cria uma organização para si mesmo não é afetado — nem quem criou a sua pelo cadastro normal. O vínculo dessas pessoas não recebe a marca e nada nesta versão volta a tocá-lo.
Organizações criadas antes desta versão não mudam. Vínculos antigos não têm a marca, e o sistema não tenta adivinhá-la: se numa instalação existe um criador que deveria ter saído, a remoção é feita à mão, com alguém olhando o caso. Essa escolha é deliberada — uma versão anterior desta correção tentou deduzir quem deveria sair e acertou o alvo errado.
Você não precisa fazer nada para adotar.
Excluir contato não destrói mais o histórico quando a ficha não sai
Excluir um contato que tinha compromisso na agenda nunca funcionava — e, na tentativa, levava junto as mensagens e as conversas dele. O CRM apagava o histórico primeiro e só então esbarrava no vínculo que barra a exclusão da ficha: a tela dizia "Erro interno", o contato continuava lá e as conversas tinham ido embora sem volta.
Antes de apagar qualquer coisa, o CRM agora confere os vínculos que barram a exclusão e devolve o mesmo aviso de vínculo pendente, com o histórico intacto. E toda tentativa que não completa passa a ficar registrada na auditoria, com o que chegou a ser apagado antes do erro — "ninguém excluiu" e "tentei e barrou" deixam de ser a mesma linha em branco.
Você não precisa fazer nada para adotar.
Excluir nó ou aresta no builder de follow-up agora pede confirmação
O botão de excluir a seleção no builder de follow-up dividia o mesmo assento da barra com o botão que apaga o fluxo inteiro: mesmo ícone de lixeira, mesma cor destrutiva, mesma posição. Os dois eram confundidos justamente porque só um deles perguntava antes — quem aprendeu que a lixeira daquele canto pede confirmação clicava no outro com a mesma confiança e perdia o trabalho do canvas sem aviso.
Agora os dois se comportam igual: clicar em Excluir (nó ou aresta) abre uma confirmação que diz o que vai embora. O título nomeia o alvo — "Excluir este nó?" ou "Excluir esta aresta?", conforme a seleção — e a frase explica a consequência: apagar um nó leva junto as arestas ligadas a ele, e não há como desfazer. A exclusão só acontece no clique de confirmação; cancelar não muda nada.
Para quem opera uma VPS, nada muda: é conserto de tela, sem comando novo, sem variável nova e sem migração. Ninguém precisa fazer nada ao atualizar.
O filtro de etiqueta do Inbox passa a oferecer as etiquetas que existem
O seletor de etiqueta do Inbox só listava as etiquetas cadastradas à mão em Configurações. Se alguém etiquetava uma conversa com algo fora daquela lista, a etiqueta aparecia na conversa mas não havia como filtrar por ela — e numa instalação recém-configurada o seletor oferecia oito etiquetas de exemplo, nenhuma delas em uso, todas devolvendo lista vazia.
Agora o seletor mostra as duas coisas juntas: as etiquetas cadastradas e as que estão realmente em uso nas conversas. E se você já estiver filtrando por uma etiqueta que saiu da lista, o seletor continua na tela mostrando qual é, em vez de sumir deixando a lista filtrada sem explicação.
O histórico de atendimentos encerrados, no painel lateral, passa a mostrar a data de cada um ao lado do desfecho.
Você não precisa fazer nada para adotar. Crédito: @paulolimajr77
O gate que exige conferência de organização passa a cobrir todas as funções privilegiadas
Nada muda na tela nem na operação: é proteção do próprio desenvolvimento.
O banco tem funções privilegiadas que rodam por cima das regras de isolamento entre organizações. Quando uma delas recebe a organização como argumento, ela precisa conferir se quem chamou pertence de fato àquela organização — senão um usuário logado numa organização a chama com o identificador de outra.
O teste que cobrava isso verificava duas funções, escritas à mão numa lista. Função nova nascia fora da lista, e nenhum gate a alcançava: em 2026-09-12 uma função escrita nesta mesma semana nasceu exatamente com esse defeito e a suíte inteira ficou verde — só apareceu porque quem a escreveu sabotou o próprio código de propósito.
Agora a pergunta é feita ao catálogo do Postgres, para todas as funções que têm a forma do risco: privilegiada, alcançável por usuário logado e recebendo a organização por argumento. Quem confere por delegação — chamando outra função que confere — é reconhecido, para o gate não acusar quem já faz a coisa certa.
O mesmo caminho já tinha sido percorrido pela pergunta vizinha ("quem pode executar esta função?"): ela também era lista fixa, virou varredura, e naquele dia 8 de 25 funções estavam expostas com todos os gates obrigatórios verdes.
A régua de recuperação para de correr para o contato anonimizado
Quando alguém pedia para ser esquecido (anonimização por LGPD), os dados eram redigidos — mas a régua de recuperação de falta continuava correndo por baixo. As mensagens de reengajamento seguiam sendo enviadas, e, quando a régua esgotava, nascia um aviso novo na Central apontando justamente para o compromisso que a anonimização tinha desligado: o aviso ressuscitava o vínculo que a LGPD mandou cortar.
Agora a cascata de anonimização cancela a régua do contato no mesmo movimento em que redige os dados — tanto pelo botão da tela quanto pelo varredor diário de retenção —, e a porta que abria aquele aviso passou a recusar contato anonimizado, como as outras três já faziam.
Você não precisa fazer nada para adotar. Contatos anonimizados antes desta versão que ainda tenham resíduo de redação são alcançados pelo varredor diário, que agora corta a régua deles também.
O botão "Limpar filtros" agora limpa também a caixa de busca
No Atendimento, "Limpar filtros" desligava os filtros e a lista voltava — mas o texto digitado continuava escrito na caixa de busca. A lista voltava cheia com um termo visível que já não valia, e quem olhasse leria aquela lista como resultado daquela busca.
Agora o botão limpa as duas coisas: o filtro e o campo.
O assistente para de dizer "confirmado" num horário que ainda espera aprovação
Quando um tipo de atendimento exige que alguém da equipe aprove, o horário marcado pelo assistente nasce reservado, não confirmado: ninguém mais consegue pegá-lo, mas ele ainda pode ser recusado.
O assistente não sabia disso. As instruções que ele recebia mandavam dizer que o horário estava confirmado logo depois de marcar — então o cliente ouvia uma confirmação que ninguém tinha dado, e podia aparecer num horário que a equipe ainda ia recusar.
Agora o assistente é avisado quando o horário apenas ficou reservado, e diz isso ao cliente: que separou o horário e que a equipe confirma.
Nada muda em atendimentos que não exigem aprovação.
O filtro "Não lidos" do Inbox passa a procurar em todas as conversas
O botão "Não lidos" só escondia as conversas já lidas da parte da lista que estava carregada na tela — ele não consultava o sistema. Numa caixa com muitas conversas, se as primeiras estivessem todas lidas, a tela mostrava "Sem conversas por aqui" e nem oferecia carregar o resto, dando a entender que não havia nada não lido quando havia.
Agora o filtro consulta todas as conversas da organização, e o botão passa a poder ser combinado com as abas e com os demais filtros.
Você não precisa fazer nada para adotar. Crédito: @paulolimajr77
O painel do Google Meet para de dizer que o envio "não foi autorizado"
Com o link pronto e ainda não enviado, o painel dizia "O envio do link ainda não foi autorizado" — que lê como recusa, quando era só o estado inicial. E logo abaixo estava o botão "Enviar link ao cliente", ativo.
Agora diz o fato: "Link não enviado ainda." O botão continua o mesmo.
"Autorizar" ficou onde é verdade: quando o atendimento muda de conversa e o sistema precisa de uma nova decisão sua.
PDFs recebidos pelo WhatsApp voltam a ser lidos pela IA
Todo PDF recebido falhava na extração de texto com "Extração de PDF indisponível: o binário nativo @napi-rs/canvas não foi instalado nesta plataforma" — mesmo a dependência estando instalada. O next build gera o .next/standalone copiando só o que o file-tracing consegue seguir por import/require estático, e o @napi-rs/canvas resolve seu binário nativo com um require() computado em runtime (por process.platform e detecção de musl/glibc); o tracer não segue isso e o binário ficava de fora da imagem — o mesmo defeito que já havia sido corrigido para o @swc/helpers. next.config.ts agora inclui o @napi-rs/canvas (e suas variantes de plataforma) na mesma lista.
De quebra, o log do cron attendant-heartbeat (AT-08) passou a registrar code/details/hint do erro do Postgres/PostgREST, não só a mensagem — uma falha observada em produção só mostrava "column ... does not exist" sem informação suficiente para diagnosticar a causa real.
Proteção de envio abre depois de mexer nos canais — e nunca mais em silêncio
Quem criava, reconectava ou excluía uma conexão e logo abria a Proteção de envio encontrava o painel sem os dados daquela conexão. A lista de conexões era atualizada, mas a ficha de limites anti-ban (pacing-knobs) ficava com o cache velho. As duas andam juntas — agora qualquer mexida nos canais invalida as duas, e o painel abre com os números certos.
Pior era o outro lado: quando a conexão já não estava mais na lista (excluída em outra aba ou máquina), o painel simplesmente não aparecia e o botão morria mudo. Agora a mesma folha abre com uma mensagem honesta — a proteção desta conexão não pôde ser carregada, ela pode ter sido removida ou a lista está desatualizada — e duas saídas: Tentar de novo, que recarrega a lista (quando a conexão reaparece, o formulário volta sozinho), e Fechar.
Nada muda para quem abre a proteção de uma conexão que está na lista: o painel é o mesmo de sempre.
O indexador RAG para de ativar versão com trechos faltando
Ao reindexar uma fonte de conhecimento (uma FAQ, um documento, o catálogo), cada trecho do material é gravado um a um. Quando a gravação de um trecho falhava, o erro ia só para o log do servidor e a indexação seguia em frente: bastava que algum outro trecho tivesse gravado para a versão nova ser dada como pronta e entrar no ar. Quem conversava com o agente passava a receber respostas apoiadas num acervo furado, e a versão anterior, completa, saía de cena sem aviso — a pessoa só descobria o buraco ao perguntar exatamente o que faltou.
Agora falha de gravação derruba a indexação inteira. Se qualquer trecho não gravar, a versão nova é registrada como falha, com o motivo (quantos trechos faltaram e em quais posições), e a versão anterior continua ativa e respondendo. O registro da falha também aponta o detalhe trechos_nao_gravados:N, para a triagem dizer de bate-pronto se o problema foi parcial. Quando nada grava, o detalhe segue sendo o nenhum_trecho_gravado de sempre.
Não muda nada quando tudo grava: a versão nova é marcada como pronta e ativada como antes, e o caminho de erro de embedding (chave ausente ou provedor recusando) continua igual, derrubando a indexação sem ativar. Quem nunca viu um buraco no índice não vê diferença nenhuma.
O rascunho do agente de IA salva antes de haver WhatsApp conectado
Numa instalação nova, quem escrevia o prompt do atendente e tentava salvar não conseguia: o editor exigia escolher "por qual número ele atende" — e, sem nenhum aparelho pareado, o seletor abria vazio. Não havia opção a escolher, e o texto recém-escrito não tinha como ser guardado. Escrever quem o agente é e conectar o celular são dois dias diferentes na vida de quem instala.
Agora o número é requisito para PUBLICAR, não para rascunhar. Sem ele o rascunho salva, e o botão "Publicar" explica o que falta e para onde ir (Conexões). Publicar sem número continua recusado em três camadas independentes — o botão, a função do banco (fn_publish_ai_agent_version) e o próprio runtime, que só executa versão publicada.
No mesmo passo, o botão "Publicar" deixa de travar para quem usa a chave de IA da instalação (a do .env): a régua pedia uma linha na tela de Credenciais, e essa escolha não é uma linha — quem instalou pelo kit via o botão desabilitado para sempre, mandando escolher a chave que tinha acabado de escolher.
O log de eventos para de encher de pendências que ninguém ia atender
O registro de eventos alimenta o painel de diagnóstico. Só que parte dos eventos nasce só para ficar registrada — mensagem enviada, lead alterado, sessão de canal mudou de estado — e nenhum consumidor de fila foi feito para eles: ninguém ia atendê-los mesmo.
Esses eventos nasciam marcados como pendentes igual a um pedido que ainda não foi processado, e assim ficavam para sempre. Numa instalação real havia 626 linhas assim, em 8 tipos de evento, todas com cara de trabalho parado na fila — e nenhuma delas ia sair dali, porque não existia quem as pegasse.
Agora o evento que é só registro nasce já fechado, e o que era acúmulo antigo foi fechado de uma vez. O que continua aparecendo como pendente é o que realmente precisa ser atendido: pedido de envio, pedido de disparo, e qualquer evento de um tipo que espere um consumidor que não exista. A fila volta a significar fila.
Não há nada a fazer na sua VPS: a correção entra junto com a atualização e o acúmulo antigo é limpo por ela.
\"Testar agente\" devolve a resposta, e para de gastar crédito em triplo
Testar um agente gastava crédito e não mostrava nada. O painel de resultado ficava em "Nenhum teste executado ainda" mesmo com o modelo tendo respondido.
A espera do navegador era de 10 segundos, e um teste de agente leva mais que isso: ele roda o motor inteiro, com as ferramentas e as verificações. Passados os 10 segundos o navegador desistia — mas o servidor não: ele terminava o trabalho e devolvia para ninguém.
Pior, ao desistir o navegador tentava de novo, até três vezes. Cada clique em "Executar teste" podia virar três execuções completas do modelo, as três cobradas, nenhuma aparecendo na tela.
Agora o teste espera o tempo que precisa, e a resposta aparece.
A regra vale para o produto inteiro, não só para essa tela: quando uma operação que ESCREVE fica sem resposta, o sistema não a repete mais. Ficar sem resposta não quer dizer que não aconteceu — quer dizer que não se sabe, e repetir uma escrita nessa dúvida é o que cobra duas vezes. Buscas e listagens continuam sendo tentadas de novo normalmente, porque ler de novo não custa nem duplica nada.
O teste do agente termina de verdade, e quando falha diz por quê
Cada execução da aba Teste de um agente deixava uma linha de execução presa em "rodando", para sempre. Numa instalação com 16 testes, eram 16 linhas paradas. O motivo era um estado que o banco não reconhecia, gravado sem ninguém conferir se a gravação tinha dado certo.
Agora a execução fecha como concluída ou falhada, com o tempo que levou.
E quando o teste falha, a causa passa a existir em algum lugar. Antes o erro era descartado sem deixar rastro: a tela dizia uma frase genérica sobre modelo e credencial, e não havia nada no log nem na execução para dizer o que realmente aconteceu. Agora o erro vai para o log do servidor e fica guardado na própria execução. A mensagem para quem opera continua a mesma, porque o texto do erro é técnico.
Os contadores de passos e tokens da execução de teste seguem em zero: esse dado não chega até ali, e preenchê-lo com um palpite seria pior que o zero.
Trocar de aba logo depois de digitar na busca para de voltar à aba anterior
Quem digitava na busca do Inbox e trocava de aba em seguida, rápido, era devolvido à aba anterior sem ter pedido. A busca continuava a valer, mas a aba voltava sozinha — e quem não sabia do problema não tinha como adivinhar a causa.
Acontecia porque o envio da busca esperava um instante depois da última tecla, e nesse instante ele guardava também qual aba estava aberta na hora da digitação. Ao ser enviado, levava a aba velha junto.
Agora ele envia apenas o que foi digitado.
Você não precisa fazer nada para adotar. Crédito: @paulolimajr77