New lock warning breaks Elixir-to-Elixir pipeline

[halostatue]

Elixir and Erlang/OTP versions

Erlang/OTP 27 [erts-15.1.2] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit]

Elixir 1.18.1 (compiled with Erlang/OTP 27)

Operating system

Linux, macOS

Current behavior

I have a workflow that runs a self-test through a pipe:

$ git clone https://github.com/KineticCafe/app_identity
$ cd app_identity/elixir
$ mix
$ mix app_identity generate --stdout | mix app_identity run --stdin

Under Elixir 1.18, I get the following exception:

** (Jason.DecodeError) unexpected byte at position 0: 0x57 ("W")
    (jason 1.4.4) lib/jason.ex:92: Jason.decode!/2
    (app_identity 1.3.2) support/app_identity/suite/runner.ex:104: AppIdentity.Suite.Runner.piped_suite/1
    (app_identity 1.3.2) support/app_identity/suite/runner.ex:68: AppIdentity.Suite.Runner.run_suites/2
    (app_identity 1.3.2) support/app_identity/suite/runner.ex:61: AppIdentity.Suite.Runner.run/1
    (mix 1.18.1) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5
    (mix 1.18.1) lib/mix/cli.ex:107: Mix.CLI.run_task/2
…

It works under Elixir 1.10 through Elixir 1.17.

The standard input read (via an inspect) is:

"Waiting for lock on the build directory (held by process 83881)\n{\n  \"name\": \"AppIdentity for Elixir\",\n …

Running these with an intermediate file (mix app_identity generate --stdout > x && mix app_identity run --stdin < x) produces no warning.

Expected behavior

The Waiting for lock… message should not be written to stdout, but to stderr.

[halostatue]

I can work around this for now by using an intermediate file, but the pipe approach is my preferred approach for this.

[jonatanklosko]

Perhaps instead of writing the output to shell.info() the task should be using IO.write() and then you can run with MIX_QUIET=1 to suppress any mix output.

@josevalim I was surprised that the lock was actually involved in this custom task, but it is because the task has @requirements ["app.start"], and app.start calls compile.

[josevalim]

I agree that maybe using IO.write with MIX_QUIET would be better, but I think we should write to stderr anyway?

[jonatanklosko]

stderr would make sense, except if we use Mix.shell().error(...) it's going to be in red, which is probably too much?

[josevalim]

I think you could do: Mix.shell().error([IO.ANSI.reset, "foo"]) or similar?

[josevalim]

We could also use IO.write + :stderr for it?

[jonatanklosko]

I think you could do: Mix.shell().error([IO.ANSI.reset, "foo"]) or similar?

This works! I think we still want Mix.shell(), so that MIX_QUIET suppresses it.

[halostatue]

Perhaps instead of writing the output to shell.info() the task should be using IO.write() and then you can run with MIX_QUIET=1 to suppress any mix output.

I’ll have to double check what I’m doing, but if I am using shell.info, I will change that to IO.write because I wasn't aware of $MIX_QUIET.