Rails 8 ganha método HTTP QUERY e as primeiras peças de Agents on Rails

O boletim This Week in Rails desta semana, assinado por Wojtek, junta duas frentes que valem atenção de quem mantém aplicação Rails em produção: o anúncio inicial do Agents on Rails e um punhado de mudanças concretas já mergeadas no framework, com destaque para o suporte ao método HTTP QUERY. Vamos separar o que é promessa do que já dá para usar.

Agents on Rails: por enquanto, anúncio

A fonte cita o lançamento de Agents on Rails e aponta para um primeiro relatório de benchmark, mas o boletim não detalha a API nem o funcionamento interno. Fica o registro honesto: é um movimento do ecossistema Rails em direção a integração com agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → no backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →, e por ora o que existe publicamente é o anúncio e um benchmark inicial. Vale acompanhar antes de apostar arquitetura em cima disso. O grosso das mudanças com valor prático imediato está no changelog do framework, e é aí que este texto se concentra.

O método HTTP QUERY chega ao roteamento

A adição mais interessante para o dia a dia é o suporte ao verbo QUERY. Trata-se de um método HTTP seguro e idempotente (como o GET), mas que carrega a consulta no corpo da requisição, e não na query string da URL. Isso resolve um problema antigo: buscas com muitos filtros ou estruturas aninhadas que estouram o limite prático de tamanho de URL ou que ficam ilegíveis codificadas em ?a=1&b=2.

No roteamento, a declaração fica direta:

# config/routes.rb
query "search", to: "search#index"
match "filter", to: "search#filter", via: :query

Do lado do controller e dos testes, o Rails expõe os helpers esperados:

request.query?                  # => true
request.request_method_symbol   # => :query

# em testes de integração
query "/search", params: { filters: { status: "active" } }, as: :json

A vantagem prática é ter uma busca idempotente e cacheável em teoria, mas com payload rico em JSON, sem gambiarra de mandar POST para uma operação que só lê dados. O trade-off: QUERY ainda é um método relativamente novo no ecossistema web. Proxies, CDNs, WAFs e clientes HTTP mais antigos podem não reconhecê-lo e barrar ou tratar de forma inesperada. Quem está atrás de infraestrutura que você não controla totalmente deve testar a cadeia inteira antes de migrar endpoints existentes. Para APIs internas ou onde você domina o stack, é uma ótima adição.

MySQL em RDS e Aurora: mudança de sql_mode que pode pegar

Essa passa despercebida no changelog mas tem potencial de mexer no comportamento de produção. Antes, o Rails anexava apenas STRICT_ALL_TABLES ao sql_mode do MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data →. O problema: em ambientes onde o sql_mode global vem vazio (o caso dos parameter groups padrão de Amazon RDS e Aurora MySQL), isso deixava de fora NO_ZERO_IN_DATE, NO_ZERO_DATE e ERROR_FOR_DIVISION_BY_ZERO, flags que o próprio MySQL 5.7+ já traz por padrão em instalações comuns.

A partir de agora o Rails anexa TRADITIONAL, que fecha essa lacuna. Na prática, aplicações rodando em RDS/Aurora podem passar a ver rejeições onde antes havia inserção silenciosa: datas zero (0000-00-00), dia zero em datas ou divisão por zero deixam de ser toleradas. É o comportamento correto e mais seguro, mas se o seu app dependia (mesmo sem saber) do modo permissivo, esse é um ponto de atenção no upgrade. Vale rodar a suíte de testes de olho em validações de data.

Correções no Active Record que valem revisar

Um bloco de ajustes mira comportamentos que já morderam gente em produção:

• normalizes roda antes da validação de tipo. Quando normalizes era combinado com um tipo que rejeita entrada inválida (como um enum do Active Record), a normalização acontecia tarde demais: o valor cru chegava ao assert_valid_value e explodia antes de ser normalizado. Agora a normalização vem primeiro, então "Pending" vira "pending" e é aceito pelo enum. Comportamento muito mais intuitivo.

• LengthValidator com minimum via proc e valor nil. O proc só era resolvido quando o valor existia, então com nil ele vazava sem resolução para a mensagem de erro e disparava NoMethodError. Agora resolve antes de montar o erro e produz o esperado "is too short".

• Bind parameters em find_by_sql/count_by_sql. Argumentos em forma de array eram interpolados via sanitize_sql em vez de usar bind parameters como o where, apesar da doc prometer paridade. Corrigido, o que é bom também do ponto de vista de consistência e segurança.

• Leitores de schema em lote. indexes, primary_keys, foreign_keys, check_constraints, exclusion_constraints e unique_constraints agora aceitam uma lista de tabelas e respondem por todas de uma vez:

connection.indexes(:users)            # => [IndexDefinition, ...]
connection.indexes([:users, :posts])  # => { "users" => [...], "posts" => [...] }

Útil para ferramentas de introspecção que antes faziam N chamadas.

Depreciações e mudanças de API que quebram código

Algumas mudanças exigem adaptação de quem toca em interno do framework:

• create como alias de insert foi depreciado nos adapters de conexão. A justificativa é semântica: insert/update/delete correspondem aos verbos DML, enquanto create soa como DDL (create_table, create_database). Se você usa create diretamente no adapter, migre para insert.

• CommandRecorder#commands mudou de formato. Cada comando gravado agora é [cmd, args, kwargs, block] (4 elementos) em vez de [cmd, args, block] com os kwargs empacotados num hash no fim de args. Código que inspeciona recorder.commands diretamente precisa se adaptar.

• ActionView::Template::Handlers::ERB virou API privada. Quem configurava opções de ERB como escape_ignore_list ali agora precisa fazer isso via ActionView::Base ou pela config action_view da railtie.

• Middleware entries separam kwargs. #args agora retorna só argumentos posicionais e há um novo #kwargs para os nomeados.

Ajustes menores que resolvem dor pontual

Ainda entram na semana: config.active_storage.video_preview_input_arguments e config.active_storage.ffprobe_arguments, que permitem passar flags de input ao ffmpeg/ffprobe (útil, por exemplo, para restringir codecs com -codec_whitelist h264,aac e endurecer o processamento de vídeo); a possibilidade de definir variant_processor como uma classe custom que implemente a interface ActiveStorage::Transformers::Transformer; o ActiveSupport::ProxyLogger que passa a silenciar mensagens por padrão de regex (ótimo para calar log barulhento de gem sem baixar o log level geral); um banner de startup no bin/rails console (desligável com RAILS_TIPS=false); e novos mapeamentos de fuso: Pacific Time (Canada) para America/Vancouver e Alberta para America/Edmonton.

Foram 28 contribuidores ao código do Rails nesta semana. A lista completa de mudanças está linkada no boletim original.

Fonte: Ruby on Rails Blog