Postmortem tècnic del 14 de juliol de 2026. Tot el que segueix està documentat en el bug 534655509 de Chromium.
El matí del 14 de juliol, qualsevol visitant de kiwop.com amb Chrome 150 que fes clic en un enllaç veia morir la pestanya: pantalla "Aw, Snap!" i un codi d'error, RESULT_CODE_KILLED_BAD_MESSAGE. La home carregava perfecta. Cada pàgina carregava perfecta si hi entraves per URL directa. Només trencava en navegar. Quatre hores després el bug va desaparèixer sense que toquéssim ni una línia, i aquesta és la part més interessant de la història.
Aquesta és la crònica de com vam acorralar el crash fins al codi font de Chromium, per què la causa més probable no era a la nostra web, i què vam aprendre sobre construir amb API experimentals en producció.
Què teníem actiu: WebMCP
WebMCP és l'API experimental de Chrome que permet a una web registrar eines per a agents d'IA: exposes funcions amb document.modelContext.registerTool() i un agent (una extensió, un assistent del navegador) les pot descobrir i executar en comptes de barallar-se amb la teva interfície a cop de clic simulat.
La teníem activa mitjançant l'origin trial oficial (Chrome 149 a 156), amb el token en una etiqueta meta de totes les pàgines. Dues eines imperatives i una declarativa al formulari del xat. Forma part de la nostra aposta per l'agentic browsing: que els agents puguin operar una web és el següent esglaó després que puguin citar-la.
A Chrome 149 tot funcionava. Amb l'arribada de Chrome 150 a estable, va començar l'espectacle.
Un crash que els health checks no veuen
El que té d'insidiós la fallada és que tota la nostra monitorització estava en verd. Els checks sintètics demanen URL i totes retornaven 200. La web estava "sana" per a qualsevol robot de vigilància i trencada per a qualsevol humà que hi navegués, perquè el crash només saltava en la navegació same-site iniciada amb un clic, la que reutilitza el procés de render de Chrome.
Primera lliçó operativa, que ja hem convertit en norma interna: després d'un canvi important, la web es passeja amb clics de veritat en un navegador de veritat. Un 200 no diu que la web funcioni, diu que el servidor respon.
La bisecció: quatre passos per acorralar-lo
En un entorn de desenvolupament vam replicar el crash i vam anar traient peces, una cada vegada:
- Eines imperatives i declarativa actives: crash.
- Només les imperatives, declarativa fora: crash.
- Origin trial actiu i cap eina registrada (
getTools()retorna una llista buida): crash igual. - Sense el token de l'origin trial (l'API ni tan sols existeix a la pàgina): navegació perfecta.
La conclusió era incòmoda però clara: no era el nostre ús de l'API. N'hi havia prou amb la presència del token per trencar la navegació de tot el lloc. Vam apagar WebMCP en producció i la web va tornar a la normalitat a l'instant.
Aquí va la segona lliçó: el token vivia en una variable d'entorn, així que apagar la feature va costar minuts. Si hagués estat incrustat a les plantilles, la web hauria seguit trencada mentre tocàvem codi a contrarellotge. Tota API experimental en producció necessita el seu interruptor d'apagada.
El que diu el codi de Chromium
Amb el foc apagat, vam investigar a fons. El primer que sorprèn: ningú havia reportat aquest crash. Ni al tracker de Chromium, ni al repositori de l'estàndard, ni a Stack Overflow. Érem, que sapiguem, els primers a veure'l.
El segon: l'origin trial estava intacte a Chrome 150. L'entrada oficial de Chrome Platform Status confirma el rang de milestones 149 a 156 sense canvis. L'única cosa que va canviar a la 150 va ser la superfície de l'API: navigator.modelContext va quedar deprecat en favor de document.modelContext.
El tercer, i aquí hi ha el quid de la qüestió: vam comparar el codi de WebMCP entre les branques de Chrome 149 i 150, i és idèntic. El gating de l'origin trial, els bindings, tot. La regressió no era al codi de WebMCP.
El que sí que vam trobar és el mecanisme exacte de l'error. Al procés principal de Chrome, el fitxer model_context_user_data.cc vigila l'estat de WebMCP document a document. Si el procés de render i el procés principal discrepen sobre si WebMCP està habilitat per a un document concret, el principal interpreta el missatge del render com a IPC il·legal i el mata. Aquest kill és literalment el RESULT_CODE_KILLED_BAD_MESSAGE que vèiem en pantalla. I no era la primera vegada que aquesta família de fallades mossegava: una CL de maig de 2026 va arreglar un crash idèntic en la seva mecànica, quan el render creia que WebMCP estava actiu i el procés principal no se n'havia assabentat.
El gir: el bug es va esfumar sense que toquéssim res
A la tarda vam intentar reproduir el crash en un perfil net de Chrome, amb el mateix build exacte (150.0.7871.115). Impossible. Vam provar vuit configuracions, inclosa una rèplica exacta de l'incident: la mateixa web, el mateix token, navegació amb clics reals. Res.
I unes hores després ja no reproduïa ni al navegador on havia fet crash tot el matí. Mateix build, mateix perfil, mateixa web, mateix token. Al nostre costat no havia canviat absolutament res.
Quan una fallada 100% reproduïble desapareix sense cap canvi al client, l'explicació que queda viu al costat del servidor. Chrome activa i desactiva funcions en calent mitjançant Finch, el seu sistema d'experiments remots: Google pot encendre una variant en un percentatge d'instal·lacions i revertir-la amb un killswitch en hores, sense actualitzar el navegador. La nostra hipòtesi de treball, i així l'hem reportat, és que un experiment relacionat amb WebMCP es va activar aquell matí, va entrar en conflicte amb l'estat per document de l'origin trial i algú a Google va prémer el botó d'apagar en veure els crashes. Des de fora no ho podem veure; Google pot comprovar-ho en el seu historial de variacions en un minut, i això és exactament el que demanem en el report.
Que consti l'honestedat: és una hipòtesi. El que sí que és un fet és la seqüència temporal, els nou bolcats de memòria que els crashes van deixar al Crashpad local i que conservem com a evidència, i que la fallada va morir sola.
El que vam aprendre, per si construeixes amb API experimentals
- Un origin trial fica Google al teu runtime. La feature pot canviar sota els teus peus sense que tu despleguis res. Assumeix-ho en el disseny: allò experimental s'aïlla i es pot apagar.
- Interruptor d'apagada o res. Variable d'entorn, flag remota, el que sigui que apagui la feature en minuts sense tocar plantilles.
- Els health checks no veuen trencaments de navegació. Després de cada canvi seriós, clics reals en navegador real. Sense excepció.
- Biseca amb una variable cada vegada. La nostra taula de quatre passos és el que converteix "se'm trenca la web" en un report que un enginyer de Chromium pot accionar.
- Guarda els minidumps. El directori Crashpad de Chrome és la caixa negra de l'accident: els bolcats del matí són l'única evidència física que queda de l'incident.
El report, i què passa ara
El cas complet és al bug 534655509, amb les pàgines de reproducció públiques que vam muntar per a l'equip de Chromium. WebMCP segueix apagat a kiwop.com i tornarà quan el bug tingui resposta o quan Chrome 151 arribi a estable, el que passi primer. El dia que torni, la web es passejarà una altra vegada a cop de clic abans de donar res per bo.
Mentrestant, la moralitat de fons no canvia: la web agèntica arriba amb API joves, experiments remots i errors que cap monitor clàssic detecta. És terreny nou, i és just on treballem. Si vols que la teva web estigui preparada per a agents sense jugar-te la navegació pel camí, comença per una auditoria d'IA o escriu-nos.
Preguntes freqüents
Què és WebMCP?
WebMCP és una API experimental de Chrome, impulsada per Google i Microsoft al W3C, que permet a una pàgina web registrar eines per a agents d'IA mitjançant document.modelContext.registerTool(). Al juliol de 2026 està en origin trial a Chrome des de la versió 149 fins a la 156, amb llançament estable previst per a la 157.
Què significa l'error RESULT_CODE_KILLED_BAD_MESSAGE de Chrome?
Significa que el procés principal de Chrome ha matat deliberadament el procés de render d'una pestanya per haver-li enviat un missatge IPC que considera il·legal o malformat. No és un penjament del render: és una execució defensiva, pensada per frenar processos compromesos. L'usuari ho veu com una pantalla "Aw, Snap!".
Què és Finch, el sistema d'experiments de Chrome?
Finch és el mecanisme de Google per activar o desactivar funcions de Chrome en remot, per percentatges d'instal·lacions i sense publicar una actualització. Cada Chrome descarrega periòdicament una "llavor" d'experiments que decideix quines variants té actives. Permet llançaments graduals i també killswitches: revertir en hores una funció que està causant problemes.
És arriscat activar un origin trial en producció?
És assumible si el tractes com el que és: codi experimental el comportament del qual pot canviar sense que tu facis res. Les tres regles que ens funcionen són aïllar la feature darrere d'un interruptor que l'apagui en minuts, verificar la web navegant de veritat després de cada canvi de versió de Chrome, i monitoritzar també els fluxos de navegació, no només els codis de resposta.
