Fix flaky tests caused by gen_workflow_hash leaking the logger level

[lmac-1]

Description

This task turns the logging volume down so its output is just the hash. There is one volume setting for the whole program, and the task never turned it back up.

Run from a terminal, that's harmless. The task prints a hash and the program exits a second later, taking the setting with it.

The test suite is different. It's one long-running program, and it calls this task as an ordinary function. So the task muted logging, and then thousands of later tests ran with it still muted. Any test checking "did this log a warning?" got nothing back, and which tests broke depended on the seed.

The fix is one question. Did this task start the program, or was it already running?

defp start_repo do
  if is_nil(Process.whereis(Lightning.Repo)) do
    Logger.configure(level: :error)
    Mix.Task.run("app.config")
    {:ok, _} = Application.ensure_all_started(:ecto_sql)
    {:ok, _} = Lightning.Repo.start_link(pool_size: 1)
  end
end

No Repo running means we're a fresh CLI invocation, so the task starts what it needs and quietens the logger as before. A Repo already running means we're a guest inside the test suite, so the task does nothing and leaves the setting alone.

That also makes the old {:error, {:already_started, _pid}} clause unreachable, so it's gone.

The Logger.configure line has to stay for the CLI. Ecto logs every query at :debug (config/config.exs:19), dev sets no logger level, and Logger writes to stdout, so without it [debug] QUERY OK lines land in the same stream as the hash. In tests it was never doing anything useful, since the suite already runs at :warning.

Same root cause as #5099, where the shared setting is the problem, but a different fix. That PR swapped in with_log, which gets the same quietening scoped to one capture. Here there was nothing worth scoping, since the quietening was useless in tests anyway, so the call is just skipped.

Validation steps

1. mix test test/mix/tasks/gen_workflow_hash_test.exs passes. Against the old version the new test fails with left: :error, right: :info, so it catches the regression rather than passing by accident.
2. mix test passes.
3. mix lightning.gen_workflow_hash <uuid> still prints only the hash.

Additional notes for the reviewer

1. Only the test path changes. Running the task from a terminal behaves as before.
2. Two files still change the shared setting, tracked under OFN-4525: resolver_test.exs and workflow_channel_test.exs. Worth a heads-up for whoever takes that ticket, because the Stop vault_test.exs mutating the VM-wide Logger level #5099 swap won't work on them. Both turn the volume up to catch :info/:debug logs that the suite's :warning setting would otherwise drop, and with_log(level: ...) can't do that. The message is discarded before the capture ever sees it.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review with Claude Code)
• I have implemented and tested all related authorization policies. (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Security Review ✅

• S0 (project scoping): N/A — diff only touches CHANGELOG.md, a mix-task logger fix in lib/mix/tasks/gen_workflow_hash.ex, and test/test_helper.exs; no new queries or web-layer entrypoints.
• S1 (authorization): N/A — no new create/read/update/delete actions or LiveView/controller handlers introduced.
• S2 (audit trail): N/A — no Repo.insert/update/delete on config resources; changes are test-hygiene and CLI logger-level scoping only.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.7%. Comparing base (fb98b9e) to head (ba6d6e9).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #5060     +/-   ##
=======================================
+ Coverage   90.6%   90.7%   +0.1%     
=======================================
  Files        422     422             
  Lines      20043   20043             
=======================================
+ Hits       18160   18172     +12     
+ Misses      1883    1871     -12     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lmac-1]

@stuartc I had a look at #5099. Although they share the same root cause, they need different fixes.

#5099 could use with_log because vault_test is a test. This is a mix task that runs from a terminal, where ExUnit isn't started, so with_log crashes with :noproc. Skipping the quietening was the only option left.

Heads up for OFN-4525: the other two files need a third approach again. They turn the level up to catch :info/:debug, which with_log can't do.

Can you review? Not urgent :)

[stuartc]

Ok after taking a closer look the changes you made do make sense. But the actual original implementation doesn't, and the behavior we're trying to preserve.

So it's a mix task that needs to start the repo, I get that. But testing a mix task directly is odd in hindsight.

TBH, if anything we should be testing the lib side (I assume we are) and if we really want to, expose maybe the function that assumes it's all running, the one that prints stuff out and/or throws an error. But I mean tbh, I wouldn't personally invest anything in testing this. I'm not aware of (not have I tried) a proper approach for testing mix tasks from the outside (without actually calling mix via a shell command).

I'd say dropping the test for the mix command entirely would be an appropriate solution here.