@xbibzlibrary/telebibz 0.4.4 → 0.4.5

package/docs/ERRORS.id.md

@@ -0,0 +1,194 @@
+# Panduan penanganan error (Bahasa Indonesia)
+
+Semua jalur error di telebibz, artinya, dan cara menanganinya — dari error API Telegram sampai kegagalan handler, timeout, dan shutdown.
+
+## Daftar isi
+
+1. [Taksonomi error](#1-taksonomi-error)
+2. [Anatomi TelegramError](#2-anatomi-telegramerror)
+3. [Rate limit 429 dan flood gate](#3-rate-limit-429-dan-flood-gate)
+4. [Error handler dan `bot.catch()`](#4-error-handler-dan-botcatch)
+5. [handlerTimeout dan `UpdateTimeoutError`](#5-handlertimeout-dan-updatetimeouterror)
+6. [Observasi error berbasis event](#6-observasi-error-berbasis-event)
+7. [Retry transport dan error jaringan](#7-retry-transport-dan-error-jaringan)
+8. [Resep penanganan error](#8-resep-penanganan-error)
+
+## 1. Taksonomi error
+
+Setiap kegagalan API Telegram adalah `TelegramError` dengan `kind`:
+
+| `kind` | Subclass | Arti | Pemicu umum |
+|---|---|---|---|
+| `rate-limit` | `TelegramRateLimitError` | Telegram menjawab 429 | Kirim terlalu cepat; `retryAfter` terisi |
+| `authentication` | `TelegramAuthError` | Token tidak valid/dicabut (401) | Token salah, bot di-revoke, logout |
+| `validation` | `TelegramValidationError` | Parameter request buruk (400) | `file_id` tidak dikenal, payload rusak |
+| `network` | `TelegramNetworkError` | Kegagalan level transport | DNS, socket, respons non-JSON, unduhan gagal |
+| `server` | — | Error server Telegram (5xx) | Transien; di-retry otomatis |
+| `retryable` | — | Error Telegram lain yang bisa di-retry | Varian flood-wait |
+| `unknown` | — | Lainnya | — |
+
+Cek `kind` saat reaksinya perlu berbeda:
+
+```ts
+import { TelegramError, TelegramRateLimitError } from "@xbibzlibrary/telebibz";
+
+try {
+  await ctx.reply("halo");
+} catch (error) {
+  if (error instanceof TelegramError) {
+    switch (error.kind) {
+      case "rate-limit":     console.log(`pelankan ${error.retryAfter}s`); break;
+      case "authentication": console.error("masalah token — berhenti"); break;
+      case "validation":     console.warn(error.message); break;
+      default:               console.error(error.message);
+    }
+  }
+}
+```
+
+`instanceof TelegramRateLimitError` juga bisa dipakai bila hanya peduli 429.
+
+## 2. Anatomi TelegramError
+
+```ts
+try {
+  await bot.api.methods.getChatMember({ chat_id: -100123, user_id: 42 });
+} catch (error) {
+  if (error instanceof TelegramError) {
+    error.kind;       // salah satu dari tujuh kind di atas
+    error.errorCode;  // error_code Telegram (400, 401, 429, …) bila ada
+    error.method;     // "getChatMember" — panggilan yang gagal
+    error.payload;    // payload yang dikirim
+    error.retryAfter; // detik, hanya untuk 429 (dari parameters.retry_after)
+    error.message;    // deskripsi dari Telegram
+  }
+}
+```
+
+## 3. Rate limit 429 dan flood gate
+
+Biasanya Anda tidak pernah melihat 429, karena transport sudah menanganinya:
+
+1. Telegram menjawab 429 dengan `parameters.retry_after`.
+2. **Flood gate** menjeda permintaan keluar *baru* selama jendela itu — melindungi seluruh trafik, bukan hanya request yang ditolak.
+3. Request yang gagal di-retry otomatis, lalu kegagalan (bila bertahan) muncul sebagai `TelegramRateLimitError`.
+
+Flood gate adalah satu-satunya jeda yang pernah diperkenalkan library — tidak pernah ada cooldown proaktif. Atur atau matikan per transport:
+
+```ts
+const bot = new Bot({
+  token: process.env.TELEGRAM_BOT_TOKEN!,
+  transportOptions: {
+    floodGate: false,   // tangani 429 sepenuhnya sendiri
+    retries: 3,         // jumlah retry untuk 429/5xx/error jaringan
+    backoffMs: 250,     // basis backoff eksponensial
+    maxBackoffMs: 8_000,
+    timeoutMs: 30_000,  // timeout per request
+  },
+});
+```
+
+Bila gate dimatikan, tangkap `TelegramRateLimitError` dan patuhi `retryAfter` — kata Telegram final:
+
+```ts
+catch (error) {
+  if (error instanceof TelegramRateLimitError) {
+    await sleep((error.retryAfter ?? 1) * 1000);
+    return retry();
+  }
+  throw error;
+}
+```
+
+## 4. Error handler dan `bot.catch()`
+
+Tanpa error boundary, handler yang melempar akan menolak `handleUpdate()` (dan webhook menjawab 500). Dengan `bot.catch()`, kegagalan diarahkan ke satu tempat:
+
+```ts
+bot.catch(async (error, ctx) => {
+  console.error("handler gagal:", error);
+
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    process.exitCode = 1;             // tak tertolak — biarkan supervisor me-restart
+    await bot.stop();
+    return;
+  }
+
+  await ctx.reply("❌ Terjadi kesalahan. Coba lagi."); // ctx = context update yang gagal
+});
+```
+
+Perilaku kunci:
+- Hanya update yang gagal yang terdampak — chat lain tetap diproses konkuren.
+- Urutan per chat tetap terjaga: update berikutnya dari chat yang sama tetap menunggu yang ini.
+- Kegagalan `broadcast()` terkumpul di report alih-alih melempar.
+
+## 5. handlerTimeout dan `UpdateTimeoutError`
+
+`handlerTimeout` (default **90 000 ms**, mengikuti Telegraf) melindungi pipeline dari handler yang menggantung:
+
+```ts
+const bot = new Bot({ token, handlerTimeout: 30_000 }); // 0 atau Infinity menonaktifkan
+```
+
+- Promise `handleUpdate()` untuk update yang menggantung melempar `UpdateTimeoutError` dan mengalir lewat `update:error` → `bot:error` → `bot.catch()`.
+- **Handler tetap berjalan di belakang** — session dan conversation tetap menyelesaikan penulisannya; timeout hanya melepaskan pipeline.
+- Urutan per chat tidak terpengaruh.
+
+## 6. Observasi error berbasis event
+
+Untuk metrik/logging yang independen dari boundary, dengarkan event bus:
+
+```ts
+bot.events.on("update:error", ({ update, error }) => {
+  metrics.increment("handler_errors", { updateId: (update as { update_id?: number }).update_id });
+});
+bot.events.on("bot:error", ({ error }) => log.error("bot error", { error }));
+bot.events.on("api:response", ({ method, durationMs }) => {
+  if (durationMs > 3_000) log.warn("panggilan api lambat", { method, durationMs });
+});
+```
+
+## 7. Retry transport dan error jaringan
+
+`FetchTransport` me-retry otomatis saat: 429 (dengan `retry_after` milik Telegram), 5xx, error jaringan, dan respons non-JSON — dengan backoff eksponensial dan jitter. Setelah `retries` percobaan, error terakhir muncul sebagai `TelegramNetworkError` (lengkap `status` dan cause terpotong). Error autentikasi (401) dan validasi (400) **tidak pernah** di-retry — retry tidak akan memperbaikinya.
+
+## 8. Resep penanganan error
+
+**Retry dengan backoff di sekitar satu panggilan** (di luar retry transport):
+
+```ts
+async function withRetry<T>(run: () => Promise<T>, attempts = 3): Promise<T> {
+  for (let i = 0; i < attempts; i++) {
+    try { return await run(); }
+    catch (error) {
+      if (error instanceof TelegramError && ["authentication", "validation"].includes(error.kind)) throw error;
+      if (i === attempts - 1) throw error;
+      await new Promise((r) => setTimeout(r, 500 * 2 ** i));
+    }
+  }
+  throw new Error("unreachable");
+}
+```
+
+**Fail cepat saat token buruk** (polling dengan token tidak valid):
+
+```ts
+try {
+  await bot.start();
+} catch (error) {
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    console.error("TELEGRAM_BOT_TOKEN tidak valid atau dicabut");
+  }
+  throw error;
+}
+```
+
+**Shutdown anggun** — `stop()` lebih dulu meng-drain handler yang berjalan:
+
+```ts
+process.on("SIGINT", () => { void bot.stop().then(() => process.exit(0)); });
+process.on("SIGTERM", () => { void bot.stop().then(() => process.exit(0)); });
+```
+
+English: [ERRORS.md](ERRORS.md) · 简体中文: [ERRORS.zh-CN.md](ERRORS.zh-CN.md)

package/docs/ERRORS.md

@@ -0,0 +1,194 @@
+# Error handling guide (English)
+
+Every error path in telebibz, what it means, and how to handle it — from Telegram API errors to handler failures, timeouts, and shutdown.
+
+## Contents
+
+1. [The error taxonomy](#1-the-error-taxonomy)
+2. [TelegramError anatomy](#2-telegramerror-anatomy)
+3. [429 rate limits and the flood gate](#3-429-rate-limits-and-the-flood-gate)
+4. [Handler errors and `bot.catch()`](#4-handler-errors-and-botcatch)
+5. [handlerTimeout and `UpdateTimeoutError`](#5-handlertimeout-and-updatetimeouterror)
+6. [Event-based error observation](#6-event-based-error-observation)
+7. [Transport retries and network errors](#7-transport-retries-and-network-errors)
+8. [Error handling recipes](#8-error-handling-recipes)
+
+## 1. The error taxonomy
+
+Every Telegram API failure is a `TelegramError` with a `kind`:
+
+| `kind` | Subclass | Meaning | Typical trigger |
+|---|---|---|---|
+| `rate-limit` | `TelegramRateLimitError` | Telegram answered 429 | Sending too fast; `retryAfter` is set |
+| `authentication` | `TelegramAuthError` | Token invalid/revoked (401) | Wrong token, revoked bot, logout |
+| `validation` | `TelegramValidationError` | Bad request parameters (400) | Unknown `file_id`, malformed payload |
+| `network` | `TelegramNetworkError` | Transport-level failure | DNS, socket, non-JSON response, download failure |
+| `server` | — | Telegram server error (5xx) | Transient; retried automatically |
+| `retryable` | — | Other retryable Telegram error | Flood-wait variants |
+| `unknown` | — | Anything else | — |
+
+Check `kind` when the reaction should differ:
+
+```ts
+import { TelegramError, TelegramRateLimitError } from "@xbibzlibrary/telebibz";
+
+try {
+  await ctx.reply("hello");
+} catch (error) {
+  if (error instanceof TelegramError) {
+    switch (error.kind) {
+      case "rate-limit":   console.log(`slow down ${error.retryAfter}s`); break;
+      case "authentication": console.error("token problem — stopping"); break;
+      case "validation":   console.warn(error.message); break;
+      default:             console.error(error.message);
+    }
+  }
+}
+```
+
+`instanceof TelegramRateLimitError` works too when you only care about 429s.
+
+## 2. TelegramError anatomy
+
+```ts
+try {
+  await bot.api.methods.getChatMember({ chat_id: -100123, user_id: 42 });
+} catch (error) {
+  if (error instanceof TelegramError) {
+    error.kind;       // one of the seven kinds above
+    error.errorCode;  // Telegram error_code (400, 401, 429, …) when present
+    error.method;     // "getChatMember" — the failing call
+    error.payload;    // the payload that was sent
+    error.retryAfter; // seconds, only for 429 (from parameters.retry_after)
+    error.message;    // Telegram's description
+  }
+}
+```
+
+## 3. 429 rate limits and the flood gate
+
+You normally never see a 429, because the transport handles them for you:
+
+1. Telegram answers 429 with `parameters.retry_after`.
+2. The **flood gate** pauses *new* outgoing requests for exactly that window — protecting all in-flight traffic, not just the request that was rejected.
+3. The failed request is retried automatically, then the failure (if it persists) surfaces as `TelegramRateLimitError`.
+
+The flood gate is the **only** delay the library ever introduces — it is never a proactive cooldown. Tune or disable it per transport:
+
+```ts
+const bot = new Bot({
+  token: process.env.TELEGRAM_BOT_TOKEN!,
+  transportOptions: {
+    floodGate: false,   // handle 429s entirely yourself
+    retries: 3,         // retry count for 429/5xx/network errors
+    backoffMs: 250,     // exponential backoff base
+    maxBackoffMs: 8_000,
+    timeoutMs: 30_000,  // per-request timeout
+  },
+});
+```
+
+If you disable the gate, catch `TelegramRateLimitError` and honor `retryAfter` yourself — Telegram's word is final:
+
+```ts
+catch (error) {
+  if (error instanceof TelegramRateLimitError) {
+    await sleep((error.retryAfter ?? 1) * 1000);
+    return retry();
+  }
+  throw error;
+}
+```
+
+## 4. Handler errors and `bot.catch()`
+
+Without an error boundary, a throwing handler rejects `handleUpdate()` (and a webhook answers 500). With `bot.catch()`, failures are routed to one place:
+
+```ts
+bot.catch(async (error, ctx) => {
+  console.error("handler failed:", error);
+
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    process.exitCode = 1;             // unrecoverable — let the supervisor restart
+    await bot.stop();
+    return;
+  }
+
+  await ctx.reply("❌ Terjadi kesalahan. Coba lagi."); // ctx is the failing update's context
+});
+```
+
+Key behaviors:
+- Only the failing update is affected — other chats keep processing concurrently.
+- Per-chat ordering is preserved: the next update of the same chat still waits for this one.
+- `broadcast()` failures are collected in the report instead of throwing.
+
+## 5. handlerTimeout and `UpdateTimeoutError`
+
+`handlerTimeout` (default **90 000 ms**, matching Telegraf) protects the pipeline from hung handlers:
+
+```ts
+const bot = new Bot({ token, handlerTimeout: 30_000 }); // 0 or Infinity disables
+```
+
+- The hung update's `handleUpdate()` promise rejects with `UpdateTimeoutError` and flows through `update:error` → `bot:error` → `bot.catch()`.
+- **The handler keeps running in the background** — sessions and conversations still complete their writes; the timeout only releases the pipeline.
+- Per-chat ordering is unaffected.
+
+## 6. Event-based error observation
+
+For metrics/ logging independent of the boundary, listen on the event bus:
+
+```ts
+bot.events.on("update:error", ({ update, error }) => {
+  metrics.increment("handler_errors", { updateId: (update as { update_id?: number }).update_id });
+});
+bot.events.on("bot:error", ({ error }) => log.error("bot error", { error }));
+bot.events.on("api:response", ({ method, durationMs }) => {
+  if (durationMs > 3_000) log.warn("slow api call", { method, durationMs });
+});
+```
+
+## 7. Transport retries and network errors
+
+`FetchTransport` retries automatically on: 429 (with Telegram's `retry_after`), 5xx, network errors, and non-JSON responses — with exponential backoff and jitter. After `retries` attempts the last error surfaces as `TelegramNetworkError` (with `status` and a truncated cause). Authentication errors (401) and validation errors (400) are **never** retried — retrying cannot fix them.
+
+## 8. Error handling recipes
+
+**Retry with backoff around a single call** (beyond transport retries):
+
+```ts
+async function withRetry<T>(run: () => Promise<T>, attempts = 3): Promise<T> {
+  for (let i = 0; i < attempts; i++) {
+    try { return await run(); }
+    catch (error) {
+      if (error instanceof TelegramError && ["authentication", "validation"].includes(error.kind)) throw error;
+      if (i === attempts - 1) throw error;
+      await new Promise((r) => setTimeout(r, 500 * 2 ** i));
+    }
+  }
+  throw new Error("unreachable");
+}
+```
+
+**Fail fast on bad tokens** (polling with an invalid token):
+
+```ts
+try {
+  await bot.start();
+} catch (error) {
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    console.error("TELEGRAM_BOT_TOKEN is invalid or revoked");
+  }
+  throw error;
+}
+```
+
+**Graceful shutdown** — `stop()` drains in-flight handlers first:
+
+```ts
+process.on("SIGINT", () => { void bot.stop().then(() => process.exit(0)); });
+process.on("SIGTERM", () => { void bot.stop().then(() => process.exit(0)); });
+```
+
+Bahasa Indonesia: [ERRORS.id.md](ERRORS.id.md) · 简体中文: [ERRORS.zh-CN.md](ERRORS.zh-CN.md)

package/docs/ERRORS.zh-CN.md

@@ -0,0 +1,194 @@
+# 错误处理指南（简体中文）
+
+telebibz 中每一条错误路径、其含义与处理方式 —— 从 Telegram API 错误到 handler 失败、超时与关机。
+
+## 目录
+
+1. [错误分类](#1-错误分类)
+2. [TelegramError 解剖](#2-telegramerror-解剖)
+3. [429 限流与 flood gate](#3-429-限流与-flood-gate)
+4. [错误处理器与 `bot.catch()`](#4-错误处理器与-botcatch)
+5. [handlerTimeout 与 `UpdateTimeoutError`](#5-handlertimeout-与-updatetimeouterror)
+6. [基于事件的错误观测](#6-基于事件的错误观测)
+7. [传输层重试与网络错误](#7-传输层重试与网络错误)
+8. [错误处理配方](#8-错误处理配方)
+
+## 1. 错误分类
+
+每个 Telegram API 失败都是带 `kind` 的 `TelegramError`：
+
+| `kind` | 子类 | 含义 | 常见诱因 |
+|---|---|---|---|
+| `rate-limit` | `TelegramRateLimitError` | Telegram 返回 429 | 发送过快；`retryAfter` 有值 |
+| `authentication` | `TelegramAuthError` | token 无效/被吊销（401） | token 错误、bot 被吊销、logout |
+| `validation` | `TelegramValidationError` | 请求参数错误（400） | 未知的 `file_id`、损坏的负载 |
+| `network` | `TelegramNetworkError` | 传输层失败 | DNS、socket、非 JSON 响应、下载失败 |
+| `server` | — | Telegram 服务器错误（5xx） | 瞬时故障；自动重试 |
+| `retryable` | — | 其他可重试的 Telegram 错误 | flood-wait 变体 |
+| `unknown` | — | 其他 | — |
+
+当不同错误需要不同反应时，检查 `kind`：
+
+```ts
+import { TelegramError, TelegramRateLimitError } from "@xbibzlibrary/telebibz";
+
+try {
+  await ctx.reply("hello");
+} catch (error) {
+  if (error instanceof TelegramError) {
+    switch (error.kind) {
+      case "rate-limit":     console.log(`放慢 ${error.retryAfter}s`); break;
+      case "authentication": console.error("token 问题 —— 停机"); break;
+      case "validation":     console.warn(error.message); break;
+      default:               console.error(error.message);
+    }
+  }
+}
+```
+
+如果只关心 429，也可以用 `instanceof TelegramRateLimitError`。
+
+## 2. TelegramError 解剖
+
+```ts
+try {
+  await bot.api.methods.getChatMember({ chat_id: -100123, user_id: 42 });
+} catch (error) {
+  if (error instanceof TelegramError) {
+    error.kind;       // 上表七种 kind 之一
+    error.errorCode;  // Telegram 的 error_code（400、401、429……），如存在
+    error.method;     // "getChatMember" —— 失败的调用
+    error.payload;    // 发出的负载
+    error.retryAfter; // 秒数，仅 429（来自 parameters.retry_after）
+    error.message;    // Telegram 的描述
+  }
+}
+```
+
+## 3. 429 限流与 flood gate
+
+通常你根本见不到 429，因为传输层已经处理了：
+
+1. Telegram 返回带 `parameters.retry_after` 的 429。
+2. **flood gate** 在该时间窗内暂停*新的*外发请求 —— 保护整个流量，而不只是被拒绝的那个请求。
+3. 被拒请求自动重试；若仍失败，最终以 `TelegramRateLimitError` 抛出。
+
+flood gate 是本库引入的唯一暂停机制 —— 从不做主动冷却。可按传输层调整或关闭：
+
+```ts
+const bot = new Bot({
+  token: process.env.TELEGRAM_BOT_TOKEN!,
+  transportOptions: {
+    floodGate: false,   // 完全自行处理 429
+    retries: 3,         // 429/5xx/网络错误的重试次数
+    backoffMs: 250,     // 指数退避基数
+    maxBackoffMs: 8_000,
+    timeoutMs: 30_000,  // 单个请求超时
+  },
+});
+```
+
+关闭 gate 后，请捕获 `TelegramRateLimitError` 并遵守 `retryAfter` —— Telegram 说了算：
+
+```ts
+catch (error) {
+  if (error instanceof TelegramRateLimitError) {
+    await sleep((error.retryAfter ?? 1) * 1000);
+    return retry();
+  }
+  throw error;
+}
+```
+
+## 4. 错误处理器与 `bot.catch()`
+
+没有错误边界时，抛异常的 handler 会让 `handleUpdate()` 拒绝（webhook 则返回 500）。使用 `bot.catch()` 把失败引到一处：
+
+```ts
+bot.catch(async (error, ctx) => {
+  console.error("handler 失败：", error);
+
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    process.exitCode = 1;             // 不可恢复 —— 交给监督进程重启
+    await bot.stop();
+    return;
+  }
+
+  await ctx.reply("❌ 出错了，请稍后再试。"); // ctx = 失败 update 的上下文
+});
+```
+
+关键行为：
+- 只有失败的 update 受影响 —— 其他 chat 继续并发处理。
+- 每 chat 顺序保持不变：同一 chat 的后续 update 仍会排队等待。
+- `broadcast()` 的失败收集在报告中，而不是抛异常。
+
+## 5. handlerTimeout 与 `UpdateTimeoutError`
+
+`handlerTimeout`（默认 **90 000 毫秒**，与 Telegraf 一致）保护流水线免受挂起 handler 的拖累：
+
+```ts
+const bot = new Bot({ token, handlerTimeout: 30_000 }); // 0 或 Infinity 表示禁用
+```
+
+- 挂起 update 的 `handleUpdate()` promise 抛出 `UpdateTimeoutError`，并依次流经 `update:error` → `bot:error` → `bot.catch()`。
+- **handler 仍在后台运行** —— session 与 conversation 照常完成写入；超时只释放流水线。
+- 每 chat 顺序不受影响。
+
+## 6. 基于事件的错误观测
+
+要独立于错误边界的指标/日志，监听事件总线：
+
+```ts
+bot.events.on("update:error", ({ update, error }) => {
+  metrics.increment("handler_errors", { updateId: (update as { update_id?: number }).update_id });
+});
+bot.events.on("bot:error", ({ error }) => log.error("bot error", { error }));
+bot.events.on("api:response", ({ method, durationMs }) => {
+  if (durationMs > 3_000) log.warn("慢速 API 调用", { method, durationMs });
+});
+```
+
+## 7. 传输层重试与网络错误
+
+`FetchTransport` 自动重试：429（遵守 Telegram 的 `retry_after`）、5xx、网络错误、非 JSON 响应 —— 采用指数退避加抖动。重试 `retries` 次后，最后一个错误以 `TelegramNetworkError` 抛出（含 `status` 与截断的 cause）。认证错误（401）和校验错误（400）**从不**重试 —— 重试无济于事。
+
+## 8. 错误处理配方
+
+**围绕单次调用的退避重试**（在传输层重试之外）：
+
+```ts
+async function withRetry<T>(run: () => Promise<T>, attempts = 3): Promise<T> {
+  for (let i = 0; i < attempts; i++) {
+    try { return await run(); }
+    catch (error) {
+      if (error instanceof TelegramError && ["authentication", "validation"].includes(error.kind)) throw error;
+      if (i === attempts - 1) throw error;
+      await new Promise((r) => setTimeout(r, 500 * 2 ** i));
+    }
+  }
+  throw new Error("unreachable");
+}
+```
+
+**token 无效时快速失败**（用错误 token 轮询）：
+
+```ts
+try {
+  await bot.start();
+} catch (error) {
+  if (error instanceof TelegramError && error.kind === "authentication") {
+    console.error("TELEGRAM_BOT_TOKEN 无效或已吊销");
+  }
+  throw error;
+}
+```
+
+**优雅关机** —— `stop()` 先排空在途 handler：
+
+```ts
+process.on("SIGINT", () => { void bot.stop().then(() => process.exit(0)); });
+process.on("SIGTERM", () => { void bot.stop().then(() => process.exit(0)); });
+```
+
+English: [ERRORS.md](ERRORS.md) · Bahasa Indonesia: [ERRORS.id.md](ERRORS.id.md)