fix(fetch): workaround Search API v2 to fix products search by IDs

[vitorrgg]

Resolve o lado cliente de ecomplus/storefront#1306.

Problema

Na Search API v2 (ecomplus.io/v2/search/_els) não existe forma de filtrar por _id que funcione no body da request:

• terms/term sobre _id → 0 hits (o mesmo doc é encontrado por sku);
• cláusulas não reconhecidas (ids, match, bool.must…) são descartadas e a busca devolve o catálogo inteiro;
• query string composta também falha: q=_id:("A" "B") AND available:true derruba doc que é available: true, e a forma que o kit emite hoje (q=visible:true AND _id:(...) via fetch(true)) devolve o catálogo inteiro (total: 167).

O que funciona de forma confiável na v2: q=_id:("A" "B") sozinho (GET). Ranges (quantity:>0, [1 TO *]) e sort não funcionam no GET.

Como setProductIds() monta terms._id no body, todo consumidor quebra silenciosamente (v-if="items.length"): vitrine de recomendados no carrinho/checkout, compre junto, favoritos da conta e composição de kit. Na v1 (apx-search) tudo isso funciona — por isso as lojas do template v2 não perceberam; as lojas Cloud Commerce apontam para a v2 via ECOMCLIENT_API_SEARCH e estão com essas vitrines vazias.

Solução

Quando a query tem filtro por _id (e sem aggs no modo complexo), o fetch():

1. envia apenas q=_id:("..." ...)&size=<n> via GET;
2. reaplica os demais filtros (term/terms/range, com resolução de campo pontilhado) no cliente, sobre o _source — regra não verificável mantém o item (conservador);
3. ordena pela ordem dos IDs pedidos (para recomendados, é a relevância do grafo; sort por sales/offers usa script painless e não é reproduzível no cliente);
4. aplica from/size no cliente e ajusta hits.total para o total filtrado — corrige de tabela o "ver mais" do RecommendedItems, que dependia de um total inconsistente.

Buscas sem _id não mudam em nada (POST DSL com aggregations, como hoje). Busca por _id com aggs no modo complexo (página de coleção com UI de filtros) também não muda — na v1 continua funcionando como sempre; na v2 continua como está hoje, documentado como limitação.

De quebra, corrige o AND dangling do tradutor simple-search quando o primeiro filtro não é term/terms (um range na primeira posição gerava q= AND ...).

Testes

Build real (npm run build) e execução do dist/ecom-search.node.js contra as duas APIs, loja 1024:

cenário	v2 antes	v2 depois	v1 depois
vitrine: 4 ids (1 sem estoque, 1 inexistente) + range quantity>0 + term available	0 hits	2 hits, ordem dos ids, só com estoque	3 hits*
paginação: setPageSize(1).setPageNumber(2)	0 hits	1 hit, página correta, total = filtrado	idem
kit: fetch(true) com 2 ids	catálogo inteiro (167)	os 2 ids exatos	os 2 ids
controle: busca por sku sem _id	ok	ok, com aggregations	ok, com aggregations

*na v1 são 3 porque o doc "sem estoque" tem estoque no índice v1 (defasado) — o filtro client-side respeita os dados do índice consultado, como deve.

standard limpo no arquivo alterado.

Limitações e follow-ups

• Sem aggregations na resposta quando a rota por _id é usada (os quatro consumidores afetados não as usam — RecommendedItems e BuyTogether deletam aggs, kit usa fetch(true)).
• Ordenação por sales/offers vira ordem dos ids pedidos.
• Depois do release: bump em @ecomplus/storefront-components / storefront-app para as lojas herdarem.

🤖 Generated with Claude Code

[leomp12]

Calma, mas aí a solução é o filtro por _id funcionar, não essa volta aqui...

[vitorrgg]

Concordo — o conserto certo é o filtro por _id funcionar no próprio _els, e é exatamente o que está especificado com curls de aceite em ecomplus/storefront#1306 (seção "Especificação para o conserto do proxy", P1–P4). Esta PR não concorre com isso: é contorno client-side reversível enquanto o proxy não muda — com o _id honrado no body, reverter é deletar o desvio no fetch e nada mais.

A pergunta que decide o destino dela: alguém pode assumir o P1 no proxy (term/terms sobre _id no body)?

• Se sim, seguro ou fecho esta PR sem release — caminho preferido.
• Se não houver previsão, sugiro mergear como paliativo: hoje, nas lojas Cloud Commerce (que apontam ECOMCLIENT_API_SEARCH para a v2), favoritos da conta e compre-junto renderizam vazio em produção, e a composição de kit via fetch(true) recebe o catálogo inteiro como resposta.

Obs.: a vitrine de recomendados do carrinho/checkout no cloud-commerce (ecomplus/cloud-commerce#812) busca via search/v1 e independe desta discussão — o que fica pendente do _els são os componentes legados acima.