# Hasil R18-6 — Uji End-to-End: OM membangkitkan DAG ingestion → Airflow 3.3.2

> **Tanggal**: 2026-10-01/02 · **Lingkungan**: PRODUKSI (Airflow 3.3.2 + OM 2.0.3)
> **Tujuan**: membuktikan jalur "OpenMetadata mengirim DAG ke Airflow" secara **utuh** —
> bukan hanya tingkat impor (itu sudah diukur di H7) — dan sekaligus menutup pertanyaan H7
> secara definitif.
> ⚠️ Uji ini **membuat** pipeline sementara di OM produksi lalu **menghapusnya kembali**.

---

## 1. VERDICT: 🟢 **BERHASIL PENUH — H7 tertutup secara definitif**

| Tahap | Hasil |
|---|---|
| OM membuat ingestion pipeline (`metadata`) untuk `trino_sicabe` | ✅ dibuat |
| OM men-deploy DAG ke Airflow (lewat plugin `/pluginsv2/`) | ✅ **HTTP 200** |
| DAG muncul di Airflow 3.3.2 | ✅ `r18_e2e_ingestion.py` |
| **Error impor** | ✅ **0** (`No data found`) |
| Trigger dari OM menjalankan DAG | ✅ HTTP 200 (percobaan ke-2) |
| **`dag_run`** | ✅ **`success`** (17 detik) |
| **`task_instance` (`ingestion_task`)** | ✅ **`success`** |

**Ringkasan dari log task (bukti terkuat):**

```
Processed records: 4 · Updated records: 0 · Errors: 0 · Success %: 100.0
Processed records: 5 · Updated records: 0 · Errors: 0 · Success %: 100.0
Workflow Success %: 100.0
Workflow finished in time: 6s 668.015ms
Done.
```

➡️ **Kesimpulan**: paket yang hilang akibat melepas extra `[airflow]`
(`tornado`, `elasticsearch`, `opensearchpy`, `providers-elasticsearch`,
`providers-opensearch`) **tidak mengganggu jalur ingestion metadata**. H7 kini bukan lagi
"terukur di tingkat impor", melainkan **terbukti sampai eksekusi**.

---

## 2. TEMUAN BARU — plugin memvalidasi LEBIH KETAT daripada server OM

Ini temuan integrasi yang belum tercatat sebelumnya, dan menjelaskan kegagalan deploy yang
sempat terjadi tiga kali:

```
POST /v1/services/ingestionPipelines/deploy/<id>   →   400
{"error":"Extra parameter 'serviceName'"}
{"error":"Extra parameter 'markDeletedTablesFromFilterOnly'"}
{"error":"Extra parameter 'serviceConnections'"}
```

**Artinya**: pipeline yang **diterima** server OM saat dibuat (`POST /v1/services/ingestionPipelines`
→ 201) bisa **ditolak saat deploy** oleh plugin di sisi Airflow. Validasi plugin lebih ketat
daripada skema server.

**Yang bekerja** — `sourceConfig.config` **paling minimal**:

```json
{ "airflowConfig": { "scheduleInterval": "0 0 * * *", "retries": 0, "startDate": <epoch-ms> },
  "name": "<nama>",
  "pipelineType": "metadata",
  "service": { "id": "<id service>", "type": "databaseService" },
  "sourceConfig": { "config": { "type": "DatabaseMetadata" } } }
```

- **Jangan** menambahkan `serviceName`, `serviceConnections`, `includeTables`,
  `markDeletedTablesFromFilterOnly`, dsb. pada `DatabaseMetadata` — ditolak sebagai
  *extra parameter*.
- Koneksi diambil dari **service record** yang sudah ada (dibuat `bootstrap.sh`) — dan
  **bekerja** ✅. (Catatan: ini berbeda dari jalur SDK yang punya masalah koneksi tersimpan
  kehilangan secret → `401`; pada jalur OM-orchestrated koneksi tersimpan justru dipakai
  dengan benar.)
- Untuk pipeline **TestSuite**, `serviceConnections` justru **diterima** (seeder DQ
  memakainya) — jadi aturan "extra parameter" itu **per tipe pipeline**, bukan global.

---

## 3. Perilaku lain yang terkonfirmasi

| Perilaku | Bukti |
|---|---|
| **Trigger gagal di percobaan pertama**, berhasil di percobaan kedua | DAG baru dibuat → `dag-processor` belum selesai mem-parsing. Perlu jeda ±20 detik (seeder DQ sudah mengantisipasi ini) |
| `airflow dags list` membaca **metadata DB**, bukan folder | Sempat menyesatkan saat uji folder mount |
| CLI Airflow 3: `airflow dags list-runs` **bukan** bentuk yang valid | Status run paling andal dibaca dari tabel `dag_run`/`task_instance` di metadata DB |
| Menghapus pipeline (`hardDelete`) menghapus **berkas DAG** dari volume | File `r18_e2e_ingestion.py` hilang; catatan DAG di DB menjadi *stale* pada siklus parse berikutnya |

---

## 4. Kebersihan setelah uji

| Item | Status |
|---|---|
| Pipeline `r18_e2e_ingestion` di OM | ✅ **dihapus** (HTTP 200, `hardDelete`) |
| Berkas DAG di volume `airflow-dags` | ✅ **hilang** (kembali 4 berkas seperti semula) |
| Catatan DAG di metadata DB Airflow | ⏳ menjadi *stale* otomatis pada siklus parse berikutnya (berkasnya sudah tidak ada) |
| DAG produksi lain | ✅ tidak tersentuh |

---

## 5. Kesalahan saya selama R18-6 (agar tidak terulang)

| # | Kesalahan | Akibat |
|---|---|---|
| 1 | Menyusun `sourceConfig.config` dengan field lengkap ala UI | Deploy ditolak 3× (`Extra parameter …`) — seharusnya mulai dari yang **minimal** |
| 2 | Menganggap semua tipe pipeline menerima field yang sama | `serviceConnections` diterima di TestSuite, **ditolak** di DatabaseMetadata |
| 3 | Memakai `airflow dags list-runs` | Bentuk CLI berbeda di Airflow 3 → pakai tabel DB |