MacOS: CLI input prompt exits if command in background exits

[LucasPickering]

Describe the bug

If you have a !command chain and a !prompt chain executing in parallel in the CLI, when the command exits it kills the input prompt. The bizarre thing is this doesn't happen with sensitive: true on the prompt (i.e. it happens with dialoguer::Input but not dialoguer::Password. It also doesn't happen if the !prompt is used first in the template, because when the prompt is rendered it opens the dialogue which blocks the main thread. This means the !command chain won't get rendered until the prompt is closed. I imagine if they were to truly render in parallel the ordering wouldn't matter.

My guess is this is related to the background process and dialoguer fighting over stdin or some other shared resource somehow. I tried explicitly setting .stdin(Stdio::null()) on the process but that did nothing. This is going to require some digging into dialoguer. I tried to reproduce it with the stdlib's synchronous Command API but couldn't, so I suspect it's related to it being a background async task.

To Reproduce

1. Save this as repro.yml:

chains:
  username:
    source: !command
      command: ["sleep", "1"]
  password:
    source: !prompt
      message: Password
    sensitive: true

requests:
  login: !request
    method: POST
    url: "https://httpbin.org/anything/login"
    query:
      sudo: yes_please
      fast: no_thanks
    headers:
      Accept: application/json
      Content-Type: application/json
    body: |
      {
        "username": "{{chains.username}}",
        "password": "{{chains.password}}"
      }

2. Run cargo run -- -f repro.yml rq login
3. You should see the Password: prompt appear, then after a second (when sleep 1 exits), it will quit
4. If you uncomment the sensitive: true line, you should see it work now

Expected behavior

The prompt stays open

Version (please complete the following information):

• OS: macOS 14.4.1
• Terminal: iTerm 3.4.23
• Slumber Version: 0.18.0

Additional context

The relevant code is:

• request.rs (where the prompt is rendered)
• render.rs (where the command is executed)

[maksimowiczm]

Can't reproduce on Linux.

[sylann]

Wild guess but the secure prompt is probably isolated.
I don't have enough knowledge on this matter but it may be preserving the prompt's futures/threads.
And I would consider this as a lucky edge case.
I couldn't confirm this yet but I was trying to find if sleep sends an exit code that somehow "bubbles too much", if that makes sense.

Sorry if my vocabulary is a bit approximative.

EDIT: small typo in your post I think, it should be -f repro.yml instead of -c repro.yml.

[LucasPickering]

I've opened an issue on console for this