Mengacu pada kekhawatiran di tulisan "I am dreading our LLM-written incident report future," otomatisasi laporan insiden berbasis LLM semakin mengandalkan representasi UI yang akurat untuk interpretasi kejadian. Jika hydration mismatch terjadi, state yang berbeda antara hasil render SSR dan client-side dapat membuat laporan LLM menafsirkan kondisi sistem dengan keliru. Artikel ini langsung menjawab bagaimana mismatch mengganggu laporan otomatis dan memberikan langkah-langkah praktis untuk mendeteksi serta mencegahnya.

Mengapa Hydration Mismatch Mengacaukan Laporan Insiden Otomatis LLM

Hydration mismatch tidak sekadar pesan di console: ia berarti DOM yang dibuat server (hasil render awal) berbeda dengan state yang di-hydrate di browser. Ketika automasi laporan insiden membaca markup atau atribut data untuk menyimpulkan status layanan, perbedaan ini bisa menghasilkan narasi salah atau data yang tidak relevan.

Contoh konkret: sebuah incident report generator mungkin membaca elemen <div data-status="..."> untuk menentukan tingkat keparahan. Jika SSR menulis status "stable" namun hydration menghasilkan "degraded", LLM akan mendapatkan dua versi status yang berkonflik, menyebabkan laporan mencampur konteks dan menyulitkan tim respon.

Penting untuk menyadari bahwa mismatch bisa berasal dari waktu data (server render menggunakan snapshot lama), side effect yang hanya dieksekusi di klien, atau logic conditional yang berbeda antara server dan klien. Diagnosa awal harus fokus pada memvalidasi bahwa data awal sama persis.

Langkah Diagnostik: Cocokkan Data Server dan Klien

1. Verifikasi data awal yang dikirim dari server

Dalam arsitektur SSR, server biasanya menyematkan payload serialisasi (misalnya window.__INITIAL_DATA__ atau __NEXT_DATA__) di HTML. Luangkan waktu untuk memeriksa payload ini dibandingkan dengan state final di browser.

Gunakan alat seperti curl atau HTTP client untuk mengambil HTML dan ekstrak JSON tersebut. Kemudian buka halaman di browser, buka console, dan bandingkan objek yang di-hydrate dengan payload awal. Hal ini mengungkap perbedaan nilai tepat ketika hydration dimulai.

2. Capture snapshot DOM dan state sebelum dan sesudah hydration

Langkah selanjutnya adalah menangkap snapshot DOM yang dihasilkan SSR dan DOM setelah hydration untuk membandingkan atribut data atau text content.

  • Dengan alat seperti Playwright atau Puppeteer, ambil HTML yang diterima browser sebelum hydration (mode network idle tapi sebelum DOMContentLoaded selesai).
  • Setelah hydration selesai, ambil kembali outerHTML dari elemen utama dan bandingkan. Gunakan diff tool untuk melihat field mana yang berubah.

Contoh Playwright sederhana untuk menangkap state:

await page.goto('https://example.com/report', { waitUntil: 'domcontentloaded' });
const ssrHtml = await page.content();
await page.waitForFunction(() => window.__HYDRATION_DONE);
const hydratedHtml = await page.content();
// Simpan kedua string untuk diff

Flag window.__HYDRATION_DONE bisa dikontrol dari bundel frontend, misalnya dengan menambahkan useEffect yang menulis true setelah hydrating. Ini memudahkan debugging karena kita tahu kapan perbandingan aman dilakukan.

3. Bandingkan hasil render dan state dengan log terstruktur

Tambahkan log terstruktur di titik-titik kunci render: sebelum render di server, saat hydrating komponen utama, dan setelah hydration selesai. Misalnya:

useEffect(() => {
  console.log('hydrated', {
    component: 'IncidentSummary',
    status: data.status,
    timestamp: Date.now()
  });
}, [data.status]);

Log ini membantu Anda mengetahui apakah props berbeda, atau jika ada side effect (misalnya fetch tambahan) yang mengubah state setelah hydration.

Jika ada mismatch, fokus pada data yang masuk. Apakah query parameter berubah? Apakah user-specific cookie memicu branch berbeda? Jawaban atas pertanyaan ini mengarah pada perbaikan logika fetching atau fallback yang konsisten.

Observability untuk Mencegah Insiden Sejenis

Untuk mencegah laporan insiden otomatis yang menyesatkan, Observability harus mencakup log, metrik, dan tooling yang memantau hydration.

1. Logging dan tracing

Log harus mencakup tag yang membedakan render server dan hydrating client. Gunakan structured logging agar backend bisa memfilter event SSR vs Client Hydration. Jika menggunakan distributed tracing, tambahkan span yang mengukur durasi hydration dan pengambilan data.

Contoh field log yang berguna: source (SSR/Client), data.version, requestId, dan hydrationDurationMs. Ini memungkinkan DevOps untuk menautkan mismatch dengan request tertentu.

2. Metrik render time dan coverage snapshot

Expose metrik seperti TimeToHydration atau TimeToInteractive dengan label page dan status. Gunakan observability platform untuk membuat alert jika durasi hydration naik signifikan, karena durasi panjang memberi peluang mismatch karena asynchronous data loading.

Untuk mencegah state berbeda, gunakan snapshot monitoring: otomatis ambil JSON string yang disematkan di HTML dalam pipeline test automation dan bandingkan dengan hasil hydrating pada browser headless. Perbedaan bisa di-trigger sebagai regression fail.

3. Tooling linting dan runtime guard

Gunakan linting build-time untuk mendeteksi akses global yang hanya tersedia di browser. Selain itu, tambahkan guard runtime untuk memastikan data server di-cache saat hydrating. Misalnya, jika komponen membutuhkan context tertentu, pastikan fallback defaultnya konsisten dan tidak bergantung pada window.

Terakhir, pertimbangkan schema validation di server payload. Payload yang tervalidasi mengurangi kemungkinan data tidak terduga yang menyebabkan mismatch.

Kesimpulan

Hydration mismatch bisa menjadi pemicu utama laporan insiden otomatis LLM yang salah tafsir. Dengan pendekatan diagnosa yang sistematis—mencocokkan payload server/klien, menangkap snapshot render, dan mencatat log- log kunci—tim frontend dapat memperbaiki sumber mismatch. Kombinasikan ini dengan observability yang monitoring render time, log terstruktur, dan tooling snapshot untuk menangkap regresi sejak dini. Dengan cara demikian, otomatisasi laporan insiden tetap akurat dan dapat diandalkan.