Open rajatjindal opened 1 month ago
FWIW, I think including this unconditionally should be ok (and expected default) when writing commands using webassembly.
I think it would be fine for this to be the default for a future e.g. spin run
plugin subcommand, but it would be very tricky to make this the default for spin up
because of multi-trigger apps.
Are we allowing multi-trigger apps today though?
but it would be very tricky to make this the default for spin up because of multi-trigger apps.
but it won't block until user explicitly blocks on stdin right? (in which case it should be ok?)
Are we allowing multi-trigger apps today though?
I mean multiple trigger executors/types.
but it won't block until user explicitly blocks on stdin right? (in which case it should be ok?)
The issue would be with multiple trigger executors trying to read stdin; spin up
should "forward" stdin to only one trigger executor.
IIRC, I saw somewhere in spin that stdin is a buffer that is passed. if that is true, then maybe it does not matter if multiple components are asking for stdin.
But also open to other suggestions? maybe an explicit config to ask for stdin?
One option would be a e.g. --stdin-trigger-type command
flag for spin up
which would only "forward" stdin to that trigger executor. I would expect that to be the default for any e.g. spin run
subcommand.
I am working on a wasm-console, which requires
stdin
capabilities. I discussed this briefly on discord and Radu suggested a fix, which worked.I wanted to check with the team if we are ok with including this unconditionally or we should make this configurable (e.g. via a trigger config)?
thanks in advance.