Atualização Entergram, semana de 25 de junho de 2026: estabilidade, ferramentas de proxy e mais de 25 correções

Esta foi uma semana de engenharia pesada na Entergram. Lançamos dois recursos novos de infraestrutura, melhoramos bastante a estabilidade para workspaces de alto volume e fechamos mais de 25 bugs em mensagens, gestão de conexões, onboarding, cobrança e tabela do CRM. Abaixo está tudo o que entrou.

Administradores agora conseguem atribuir o tráfego de proxy a rotas e contas conectadas específicas, o que dá visibilidade sobre quais conexões consomem mais banda. Junto disso, agora é possível designar proxies estáticos dedicados a rotas individuais. Isso é útil quando você precisa de um IP previsível e estável para determinadas contas de Telegram, em vez de deixar o pool rotacionar.

DEV-149 no Linear

Um worker em segundo plano agora testa cada proxy periodicamente e atualiza seu estado de saúde. Ou seja, o painel administrativo passa a refletir a conectividade real, e você identifica proxies degradados antes que eles afetem os usuários em silêncio, em vez de descobrir o problema por meio de tickets de suporte.

DEV-151 no Linear

Workspaces grandes, com centenas de chats distribuídos por muitas contas conectadas, vinham sofrendo bloqueio significativo da thread principal e travamentos no navegador. Nesta semana reformulamos o motor de conexão ws-v2 para limitar rajadas de account.bind e espaçar as chamadas de folder.chats.fetch. O resultado: uma sessão de QA que antes gerava 692 tarefas longas e cerca de 166 segundos de bloqueio da thread principal agora carrega sem travar.

DEV-191 no Linear

Contas em workspaces movimentados exibiam os selos "Reconnect Required / Disconnected" mesmo quando a sessão MTProto do backend estava viva e servindo tráfego. Operadores que clicavam em Reconectar disparavam logins desnecessários e, em alguns casos, esbarravam em limites de FLOOD_WAIT do Telegram no número de telefone. Agora o selo só aparece quando existe um problema real de conexão.

DEV-177 no Linear

Mensagens de áudio voltaram a tocar. Mensagens de voz recebidas falhavam em silêncio, e o botão de reproduzir não fazia nada. Corrigido em todos os tipos de chat. (DEV-133)

Erros de "socket closed" resolvidos. Alguns workspaces sofriam desconexões abruptas com um erro de contexto em chat.subscribe. A lógica de reconexão do socket está estável. (DEV-120)

Histórico de supergrupos e canais carrega corretamente. Navegar em supergrupos disparava erros de "Invalid realtime command payload" no caminho history.around quando o frontend enviava dicas de peer (entity_class_name) que o gateway não reconhecia. Corrigido na camada do gateway. (DEV-168, PRODUCT-121)

A página não congela mais durante conversas ou encaminhamentos. Resolvemos uma classe de travamentos que obrigava operadores a recarregar a página no meio do atendimento. (DEV-143)

Status online consistente. O indicador de presença na tabela de chats e o do cabeçalho da conversa liam fontes diferentes. Agora ambos compartilham um único estado de presença resolvido. (DEV-186)

Nomes corretos de remetente em grupos. Balões de mensagem em conversas de grupo às vezes exibiam o nome de usuário errado acima do conteúdo. Corrigido nos caminhos chat_list.window.snapshot e live_chat_list.delta. (DEV-192)

Contadores de não lidas precisos. Vários cenários faziam o contador exagerar. Por exemplo, enviar 2 mensagens e ver 5 marcadas como não lidas. O contador agora se reconcilia corretamente entre reconexões. (DEV-135)

Balões duplicados corrigidos. Quando duas ou mais contas conectadas participavam do mesmo chat, a mesma mensagem podia aparecer duas vezes na conversa aberta. Era um bug de deduplicação na renderização do frontend, não um problema de fusão entre contas. Corrigido. (DEV-183)

Fallback de remetente e autores de reações resolvidos. O histórico às vezes mostrava other como rótulo de remetente em mensagens recebidas, e os popovers de reação ficavam presos em "Loading reactions". Os dois casos foram corrigidos. (DEV-156)

Chats permanecem na visualização de pasta depois da resposta. Pastas com a opção "excluir chats lidos" removiam o chat no instante em que o operador enviava uma resposta, fazendo a conversa sumir no meio do atendimento. Agora as pastas preservam os chats respondidos até você sair da visualização. (DEV-178)

MCP envia para contatos novos. A integração MCP dava erro ao tentar enviar mensagem para um contato do Telegram com quem você nunca havia conversado. O primeiro envio agora funciona. (DEV-141)

Sessões mortas se recuperam sozinhas. Um bug na lógica de capacidade de rotas do agente de sessão (observeRoutes) fazia com que algumas sessões parassem de reiniciar depois de cair. As contas afetadas retornavam nats: no responders em toda requisição de histórico ou de pasta, e reiniciar o agente não resolvia. O problema de starvation foi corrigido e as sessões mortas voltam à vida por conta própria. (DEV-139)

O diálogo de conexão do ws-v2 não inunda mais com erros 400. Um problema de temporização fazia o loop de polling da conexão de conta consultar um ID de sessão de autenticação inexistente, produzindo centenas de avisos de API request failed: 400 em uma única sessão. Corrigido no ciclo de vida do polling. (DEV-181)

Status da conexão de proxy aparece corretamente nas Configurações. O indicador de proxy ficava travado em "carregando" sempre que você visitava a página de Configurações, mesmo com conexões saudáveis. Agora reflete o estado real. (DEV-154)

Usuários entram em workspaces de forma confiável. Um erro de profundidade máxima de atualização do React (#185) era disparado sempre que um usuário novo chegava à tabela de chats do CRM depois de entrar. A causa raiz era uma referência de array reinstanciada dentro da definição de CHAT_PAGE_SIZE_OPTIONS, agora movida para fora do ciclo de renderização. (DEV-165, DEV-167)

Aceitação de convites no onboarding corrigida. Usuários que colavam um link de convite durante o onboarding conseguiam concluir o fluxo sem de fato entrar no workspace de destino, caindo em um workspace pessoal vazio e depois quebrando ao navegar para Configurações e Tabela de Chats. A lógica de aceitação e redirecionamento está correta. (DEV-170)

Usuários removidos não voltam. Membros removidos ou que saíram do workspace eram trazidos de volta a cada atualização de página por causa de uma sessão antiga de link de convite. O endpoint /api/onboarding agora verifica o status de participação antes de reincluir alguém. (DEV-175)

Pedidos de troca de e-mail podem ser cancelados. O botão de cancelar uma troca pendente não estava ligado a nenhuma ação, e clicar nele não fazia nada. Agora ele cancela o pedido corretamente. (DEV-137)

Seleção de chats visível no tema claro. Selecionar linhas de chat no tema claro produzia destaques quase invisíveis por causa de um token de contraste ausente. Corrigido. (DEV-157)

Donos em teste compram assentos sem bater em um erro sem saída. Chamar purchaseSeat() antes de o dono ter uma assinatura paga ativa retorna 400 OWNER_SUBSCRIPTION_REQUIRED. Agora donos em período de teste veem um aviso claro para assinar primeiro, com caminho direto para a página de assinatura. (DEV-174)

Compras de assinatura funcionam de forma confiável. Resolvemos uma classe de conflitos de autenticação 401/403 no checkout, causados por invalidação de sessão durante o redirecionamento para o Stripe. (DEV-172)

Mídia e vídeo reproduzem sem erros de limite de taxa. O endpoint /api/realtime/media estava sujeito a um limitador genérico de 20 requisições por minuto. A reprodução de vídeo no navegador faz várias requisições de faixa de bytes para o mesmo arquivo, o que estourava o limite em menos de um segundo. Requisições de mídia agora ignoram o limitador genérico. (DEV-152)

Busca completa e consistente. Algumas buscas retornavam resultados parciais ou davam erro de "Telegram Search is unavailable" na primeira consulta, e só funcionavam na segunda tentativa. Corrigido: os resultados voltam corretamente já na primeira requisição. (DEV-136)

"Tempo desde a primeira mensagem recebida" conta a partir do Telegram, não da abertura do app. A coluna especial iniciava o relógio no momento em que você abria a Entergram, e não quando a mensagem foi recebida pelo Telegram. A fonte do carimbo de tempo agora está correta. (DEV-162)

Uma lista de correções só vira valor quando alguém checa o que mudou na prática. Três verificações rápidas valem o tempo da sua equipe.

Revise seus proxies. Se o seu workspace opera várias contas pessoais de Telegram, abra o painel administrativo e olhe o novo estado de saúde por rota. Contas que apresentavam quedas inexplicadas quase sempre estavam atrás de um proxy degradado. Onde houver uma conta crítica, considere fixar um proxy estático dedicado em vez de deixá-la no pool rotativo.

Confira as pastas que excluem chats lidos. Times de suporte que criaram pastas com a opção de excluir chats lidos costumavam contornar o comportamento antigo evitando responder dentro da pasta. Esse contorno não é mais necessário, e vale revisar os filtros salvos para simplificá-los.

Revalide contadores e presença. Se algum operador tinha o hábito de ignorar o selo de não lidas por desconfiança, avise a equipe de que o contador voltou a ser confiável. Hábitos criados em torno de um bug sobrevivem à correção, portanto comunicar a mudança faz parte do trabalho.

Vale explicar por que uma semana inteira foi dedicada a desempenho em vez de novidades visíveis. A Entergram é uma camada sobre o Telegram feita para escala: um workspace com mais de 100 contas conectadas gera um volume de eventos em tempo real muito maior do que uma caixa de entrada comum. Quando a thread principal do navegador bloqueia por dois minutos, o operador não vê um gráfico bonito, ele vê um app que não responde.

As mudanças no ws-v2 desta semana atacam exatamente essa camada, espaçando a vinculação de contas e a carga de pastas para que o navegador respire. O ganho aparece nos números de QA, mas o que importa é o efeito no dia a dia: menos recarregamentos, menos reconexões desnecessárias e menos risco de bater em limites de FLOOD_WAIT do Telegram por causa de logins repetidos que nunca precisaram acontecer.

Se a sua equipe opera muitas contas e quer entender como organizar tudo isso em um único lugar, comece pelo CRM para Telegram e pelas análises de mensagens.

O changelog completo da v0.16.0 e de todas as versões anteriores está na página de novidades da Entergram.