Belajar Zellij - Session Persistence & Resurrection

#Pendahuluan

Setelah di episode 16 kalian berhasil membangun plugin pertama berbasis Rust dan WASM, sekarang kita naik satu level: membuat workspace kalian tidak hanya nyaman, tetapi juga tidak mudah hilang. Episode 17 ini membahas Session Persistence & Resurrection — kemampuan Zellij untuk mencatat seluruh keadaan sebuah session ke disk secara otomatis, lalu menghidupkannya kembali kapan pun dibutuhkan, bahkan setelah komputer reboot.

Bayangkan skenario yang paling menyakitkan: kalian sedang men-debug masalah rumit dengan lima pane terbuka — editor, log server, test runner, dan dua pane shell — lalu tiba-tiba laptop mati karena baterai habis. Tanpa persistence, semua konteks itu hilang dan kalian harus membangun ulang dari nol, mengingat-ingat perintah mana yang sedang berjalan di pane mana. Dengan session resurrection, Zellij menyimpan semuanya secara otomatis setiap detik, dan kalian cukup mengetik satu perintah untuk kembali ke titik sebelum semuanya runtuh.

Mengapa ini penting? Karena detach saja tidak cukup. Detach membuat session bertahan selama proses Zellij server masih hidup; begitu mesin reboot, semua session ikut mati. Resurrection adalah jawaban untuk lapisan berikutnya: session yang mati bisa dilahirkan kembali dari catatan. Di episode ini kita membahas mekanisme serialisasi session di balik layar, konfigurasi session_serialization dan opsi-opsi turunannya, cara mengelola serta me-restore session lewat CLI dan session-manager, lalu bagaimana working directory, environment, dan scrollback ikut disimpan. Di akhir episode, kalian akan memiliki workflow yang mampu bertahan dari reboot tanpa kehilangan satu pane pun.

#Bagaimana Session Resurrection Bekerja

Sejak versi 0.39, Zellij memiliki built-in session resurrection. Setiap session yang sedang berjalan diserialisasi ke disk secara berkala — tepatnya, Zellij menulis data session ke sistem cache setiap satu detik. Data yang dicatat meliputi layout session: jumlah tab, susunan pane, working directory setiap pane, dan perintah yang sedang berjalan di pane-pane bertipe command pane. Ketika sebuah session berakhir — baik ditutup sengaja lewat Ctrl+q, mati karena crash, maupun server Zellij dihentikan — data tersebut tidak dibuang; ia disimpan sebagai session yang "keluar" dan siap di-resurrect.

Penting untuk memahami perbedaan antara dua istilah ini: attach dan resurrect.

Ketika kalian me-resurrect sebuah session, Zellij membangun ulang tab dan pane, memulihkan working directory masing-masing, lalu meletakkan perintah yang dulu berjalan di balik banner Press ENTER to run.... Desain ini disengaja: Zellij tidak menjalankan ulang perintah secara membabi buta, karena perintah seperti rm -rf tidak boleh tereksekusi hanya karena kalian menekan Enter pada prompt resurrect. Kalian harus menegaskan, satu per satu atau sekaligus, bahwa perintah itu memang ingin dijalankan.

Hasil serialisasi itu sendiri disimpan sebagai file layout KDL di folder cache Zellij — pada Linux biasanya di ~/.cache/zellij/. Buka salah satu file tersebut dan kalian akan menemukan struktur yang familier, persis seperti layout yang kalian tulis sendiri:

layout {
    session_name "dev"
    tab name="Editor" {
        pane command="nvim"
        pane command="cargo watch -x run"
    }
    tab name="Logs" focus=true {
        pane command="journalctl -f"
    }
}

Karena formatnya KDL standar, file ini bisa dibaca, diedit, dan dimuat ulang dengan zellij --layout. Ini membuka kemungkinan yang menarik: sesi kerja yang dulu ad hoc kini bisa menjadi layout resmi yang kalian versi-kan bersama kode, atau dijadikan titik awal untuk kolaborasi tim.

#Mengaktifkan Persistence dengan Konfigurasi

Fitur resurrection aktif secara default. Di config.kdl, opsi ini berada di blok options dan bernama session_serialization. Kalian bisa mengecek atau memodifikasinya seperti ini:

options {
    session_serialization true
    pane_viewport_serialization true
    scrollback_lines_to_serialize 50000
    default_cwd "~/projects"
}

Opsi pertama, session_serialization true, adalah saklar utama: ia memastikan layout, tab, pane, dan perintah yang berjalan ikut diserialisasi. Dua opsi berikutnya memperdalam tingkat ketelitian pemulihan:

pane_viewport_serialization adalah opsi yang membuat resurrection terasa seperti "mesin waktu": bukan hanya layout yang kembali, tapi isi layar dan sejarah scrollback tiap pane ikut dipulihkan. scrollback_lines_to_serialize berguna untuk membatasi beban — nilai 0 berarti menyimpan seluruh scrollback, yang tentu memakan ruang cache lebih besar. post_command_discovery_hook berguna untuk kasus di mana Zellij gagal mendeteksi perintah yang berjalan karena dibungkus wrapper, misalnya untuk men-strip prefix sudo dari perintah yang ditemukan.

#Mengelola & Me-restore Session lewat CLI

Setelah resurrection aktif, perintah zellij ls (list-sessions) tidak hanya menampilkan session yang sedang berjalan, tetapi juga session yang sudah keluar dan masih tersimpan:

zellij ls

Session name          Status
dev                   RUNNING
pipeline              EXITED - attach to resurrect

Untuk me-resurrect, cukup attach ke session tersebut — Zellij akan mendeteksi bahwa session sudah tidak hidup dan membangunnya ulang dari data yang terserialisasi:

zellij attach pipeline

Jika kalian yakin semua perintah yang direkam aman untuk dijalankan, tambahkan --force-run-commands untuk melewati banner konfirmasi dan langsung menjalankan semuanya:

zellij attach pipeline --force-run-commands

Session yang sudah keluar dan tidak lagi dibutuhkan bisa dihapus permanen. Ingat perbedaannya: kill-session hanya berlaku untuk session yang masih hidup, sedangkan delete-session menghapus session yang terserialisasi:

zellij delete-session pipeline
zellij delete-all-sessions

Ada satu cara lain yang menarik: karena data resurrection disimpan sebagai file layout KDL, file tersebut bisa dimuat seperti layout biasa — bahkan bisa dibagikan ke mesin lain. Dua pendekatan restore tersebut bisa kalian bandingkan:

zellij attach pipeline

zellij --layout session-layout.kdl

Cara kedua berguna ketika kalian ingin menyimpan snapshot sebuah session sebagai layout permanen, memodifikasinya, atau membagikannya ke rekan satu tim. Layout hasil serialisasi pada dasarnya adalah KDL biasa yang bisa dibaca dan diubah.

Cara yang lebih nyaman untuk melakukan semua operasi ini adalah lewat session-manager, plugin bawaan yang bisa dibuka dengan Ctrl+o lalu w. Di dalamnya, session yang masih hidup dan yang sudah keluar ditampilkan dalam satu daftar; tekan Tab untuk beralih menampilkan session EXITED, lalu pilih dengan Enter untuk me-resurrect. Operasi hapus permanen juga bisa dilakukan langsung dari antarmuka ini, tanpa perlu keluar dari session. Antarmuka ini juga melakukan pencarian fuzzy terhadap nama session, sehingga berpindah atau memulihkan session di antara puluhan workspace terasa ringan. Detail lengkap session-manager akan kita bedah di episode 18.

#Working Directory & Environment per Session

Persistensi tidak hanya soal layout; Zellij juga merekam environment tempat session berjalan. Ada dua hal yang perlu kalian pahami: working directory dan environment variables. Keduanya bisa ditetapkan sejak awal lewat layout, sehingga ketika session di-resurrect, semuanya kembali ke tempat yang benar.

layout {
    template {
        ZELLIJ_ENV "production"
        APP_LOG_LEVEL "debug"
    }
    tab name="editor" {
        pane cwd="/srv/app" command="nvim"
    }
    tab name="shell" {
        pane cwd="/srv/app"
    }
}

Blok template mendefinisikan environment variables yang diinjeksi ke setiap pane dalam session. Karena variabel ini diset pada saat session dibuat, metadata-nya ikut tersimpan bersama data resurrection — begitu session dibangun ulang, variabel tersebut tersedia kembali. Sementara itu, atribut cwd pada setiap pane menentukan direktori kerja; pada saat resurrect, Zellij memulihkan posisi kalian di direktori yang sama.

#Menangkap Scrollback untuk Dokumentasi

Kadang kalian butuh lebih dari sekadar memulihkan session — kalian ingin menyimpan bukti berupa isi scrollback untuk dokumentasi atau laporan insiden. Zellij menyediakan beberapa jalan untuk ini.

Cara interaktif: masuk ke Scroll mode dengan Ctrl+s, lalu tekan e untuk membuka seluruh scrollback pane aktif di $EDITOR. Kalian bisa menyimpan file itu, atau bahkan langsung merapikannya sebelum disimpan. Cara otomatis: gunakan CLI action dump-screen, yang mengeluarkan isi viewport dan scrollback ke STDOUT sehingga bisa diarahkan ke file:

zellij --session dev action dump-screen --full > /tmp/dev-output.txt

Perintah ini bekerja dari dalam maupun luar session — kalian cukup menyebut session mana yang ingin diambil isinya. Kombinasi dump-screen dengan resurrection membuat workflow dokumentasi insiden menjadi lengkap: scrollback disimpan sebagai artefak, dan jika konteksnya masih diperlukan, session-nya bisa di-resurrect untuk melanjutkan penyelidikan.

Pola yang lebih canggih: karena scrollback juga bisa diserialisasi melalui pane_viewport_serialization, kalian tidak perlu menyimpan file dump setiap saat. Cukup pastikan opsi tersebut aktif, biarkan Zellij merekam scrollback secara berkala, dan ambil dump-screen hanya ketika benar-benar dibutuhkan. Dengan begitu, dokumentasi insiden selalu tersedia, dan jejak kerja yang sedang berlangsung tetap aman bahkan ketika kalian lupa menyimpan apa pun secara manual. Untuk alur yang lebih otomatis, episode 13 menunjukkan bagaimana pipe dan CLI actions bisa memicu pengambilan snapshot pada saat tertentu — misalnya ketika sebuah test gagal atau proses build selesai.

#Kesalahan Umum (Common Pitfalls)

1. Menggunakan kill-session untuk session yang sudah keluar. kill-session hanya mematikan session yang masih hidup; session yang terserialisasi dihapus dengan delete-session. Mencampur keduanya bikin kalian heran kenapa session "tidak mau mati" — padahal statusnya memang EXITED.
2. Berharap proses yang berjalan dipulihkan persis. Resurrection memulihkan layout dan perintah, bukan state di dalam memori. REPL, hasil komputasi, dan output yang belum di-commit akan kembali ke keadaan awal. Jika kelangsungan proses itu yang kalian butuhkan, jangan tutup session — gunakan detach (Ctrl+o lalu d) agar proses terus berjalan.
3. Mengaktifkan pane_viewport_serialization true tanpa batas scrollback. Cache folder Zellij bisa membengkak drastis. Selalu pasang scrollback_lines_to_serialize dengan nilai yang masuk akal, dan pantau ukuran cache jika kalian menjalankan banyak session sekaligus.
4. Menutup session berharga tanpa rename. Daftar resurrect penuh session bernama random yang tidak bisa dibedakan, sehingga membuka kembali konteks yang benar menjadi pekerjaan detektif. Biasakan rename via session-manager sebelum Ctrl+q.
5. Menyimpan secrets di environment shell manual. Variabel yang di-export manual tidak diserialisasi dan — lebih penting — tidak aman disimpan sebagai bagian dari session. Simpan secrets di tempat terpisah, bukan di layout template, dan biarkan aplikasi mengambilnya dari environment aman di runtime.

#Penutup

Di episode 17 ini kalian telah membekali workspace Zellij dengan memori jangka panjang. Kita memulai dari mekanisme kerja session resurrection — serialisasi otomatis setiap detik yang merekam layout, tab, pane, dan perintah berjalan — lalu mengatur ketelitian pemulihan melalui session_serialization, pane_viewport_serialization, dan scrollback_lines_to_serialize. Kalian juga belajar mengelola session keluar lewat zellij ls, attach, delete-session, serta memanfaatkan file layout hasil serialisasi, menetapkan working directory dan environment per session lewat layout, dan menangkap scrollback untuk dokumentasi.

Poin yang harus kalian bawa:

• Resurrection berbeda dari attach: attach ke session hidup, resurrect membangun ulang session yang keluar.
• Perintah yang di-resurrect berada di balik banner Press ENTER to run... demi keamanan.
• session_serialization aktif secara default; perbesar ketelitian dengan pane_viewport_serialization.
• delete-session untuk menghapus session keluar, kill-session untuk yang masih hidup.
• Layout hasil serialisasi bisa dimuat ulang dan dibagikan lintas mesin.

Ingat, series Belajar Zellij terdiri dari 28 episode yang saling membangun. Persistence membuat session kalian bertahan, tetapi hidup dengan banyak session sekaligus menuntut manajemen yang rapi. Di episode 18 selanjutnya kita membahas Session Manager & Multi-Session Workflow: memakai plugin session-manager untuk menavigasi, me-rename, dan berpindah session, pola satu session per proyek, workflow paralel, dan integrasi fzf untuk berpindah session secepat kedipan mata. Sampai jumpa di episode 18!