Plugin gets permissions revoked for a short time on attach

[dj95]

Basic information

zellij --version: zellij 0.39.0 (commit: bf41b17cc6e6208447160b259cbfc853d1b9c2cf) stty size: 33 162 uname -av: Linux eba3fd94c78b 5.15.82-0-virt #1-Alpine SMP Mon, 12 Dec 2022 09:15:17 +0000 aarch64 GNU/Linux (also occurs on macOS Darwin Daniels-MacBook-Pro.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000 arm64) rust-plugin-example: commit 3d6987dcafae80fdb61fed0f796265c7d671ff62

List of programs you interact with as, PROGRAM --version: output cropped meaningful, for example: kitty --version: kitty 0.30.1

Further information

When playing around with the newly introduced run_command api (thanks again for that, it's really great!) I've noticed, that there occurred problems with the plugin permissions, when detaching and re-attaching to a session. Since I was not sure if it occurred due to my plugin, I've tested it with the rust-plugin-example in a docker container, such that the environment is as clean as possible. Since it might be a bit too much details, I'll first describe the simplified reproduction steps and later on the detailed one, in case you need them.

Here's the layout file used. It loads a compiled version of the rust-plugin-example after it is compiled.

layout {
    pane split_direction="vertical" {
        pane
    }
    pane size=2 borderless=true {
        plugin location="file:./target/wasm32-wasi/debug/rust-plugin-example.wasm"
    }
}

With the layout file, execute the following steps:

zellij -l ./layout.kdl --session debug

# detach from the session

zellij a debug

Then the log file prints the following errors:

INFO   |zellij_client            | 2023-10-20 16:58:46.662 [main      ] [zellij-client/src/lib.rs:156]: Starting Zellij client!
INFO   |zellij_server            | 2023-10-20 16:58:46.666 [wasm      ] [zellij-server/src/lib.rs:917]: Compiling plugins using Cranelift
ERROR  |zellij_server::plugins::w| 2023-10-20 16:58:46.676 [async-std/runti] [zellij-server/src/plugins/wasm_bridge.rs:878]: PluginId '0' permission 'ReadApplicationState' is not allowed - Event 'ModeUpdate' denied
ERROR  |zellij_server::plugins::w| 2023-10-20 16:58:46.678 [async-std/runti] [zellij-server/src/plugins/wasm_bridge.rs:878]: PluginId '0' permission 'ReadApplicationState' is not allowed - Event 'TabUpdate' denied
ERROR  |zellij_server::plugins::w| 2023-10-20 16:58:46.678 [async-std/runti] [zellij-server/src/plugins/wasm_bridge.rs:878]: PluginId '0' permission 'ReadApplicationState' is not allowed - Event 'ModeUpdate' denied

Basically it just prints the log and does not get the permissions for some events. After a short amount of time the events are received properly, when the PermissionRequestResult event was reissued again.

---

Here are the detailed steps including the docker setup.

docker run --rm -it --entrypoint=/bin/bash rust

All following steps were executed in the started container:

git clone https://github.com/zellij-org/zellij
cd zellij
rustup target add wasm32-wasi
cargo xtask build
cd ..

git clone https://github.com/zellij-org/rust-plugin-example
cd rust-plugin-example
rustup target add wasm32-wasi
cargo build

# create the layout file
../zellij/target/debug/zellij -l ./layout.kdl

# detach

../zellij/target/debug/zellij a

# check logs
cat /tmp/zellij-0/zellij-log/zellij.log

Feel free to message me in case you need further information or details.

[imsnif]

Looks like a bit of a race condition for sure, but for me even though a few events are lost at the beginning this fixes itself pretty quickly - no? Not saying it's desirable of course, just that it's not extremely critical until we massage some transaction-goodness into the event system...

[dj95]

It does recover quickly. I think as well, that it's not a critical issue. Might be good to mention it within the documentation, such that plugin developers do not rely on the behaviour.

Was in my case a bit strange as the plugin received an event, but it had no permissions to execute commands at this point. A retry implementation mitigated the issue though.