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:

{ "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

4.8 KiB Raw Blame History Unescape Escape