mix gettext.extract --merge crashes on our codebase because the merge step added in #417 runs with a fixed 120-second timeout:
** (exit) exited in: Task.Supervised.stream(120000)
** (EXIT) time out
(elixir 1.19.5) lib/task/supervised.ex:349: Task.Supervised.stream_reduce/7
(elixir 1.19.5) lib/stream.ex:707: Stream.run/1
(gettext 1.0.2) lib/mix/tasks/gettext.extract.ex:85: Mix.Tasks.Gettext.Extract.run_message_extraction/3
gettext 1.0.2, Elixir 1.19.5, OTP 28.
I know #416 already covered this once: the old 5s default got raised to 120s, and the review landed on a fixed value rather than :infinity because of CI concerns. Fair enough, but 120s is still a ceiling, and we're well past it. Our app has ~3,300 files and a default.po with ~10k messages across 5 domains; the merge alone takes about 6 minutes on an Apple Silicon laptop. So the task dies every single run.
Two details that make it worse in practice:
- The crash lands after the POT files (and some of the smaller PO files) are already written, so you're left with a half-updated working tree and a raw
Task.Supervised.stream exit that gives no hint what happened.
- Standalone
mix gettext.merge doesn't have this limit: its own Task.async_stream uses timeout: :infinity (lib/mix/tasks/gettext.merge.ex:213). Running mix gettext.extract && mix gettext.merge priv/gettext works fine on the same project. Having the ceiling only on the combined flag seems unintentional.
Would you take a PR that makes the timeout configurable, say via the project's :gettext config or a --merge-timeout flag, keeping 120s as the default? Failing that, even a note in the task docs pointing at the two-step workaround would help the next person who hits this.
mix gettext.extract --mergecrashes on our codebase because the merge step added in #417 runs with a fixed 120-second timeout:gettext 1.0.2, Elixir 1.19.5, OTP 28.
I know #416 already covered this once: the old 5s default got raised to 120s, and the review landed on a fixed value rather than
:infinitybecause of CI concerns. Fair enough, but 120s is still a ceiling, and we're well past it. Our app has ~3,300 files and a default.po with ~10k messages across 5 domains; the merge alone takes about 6 minutes on an Apple Silicon laptop. So the task dies every single run.Two details that make it worse in practice:
Task.Supervised.streamexit that gives no hint what happened.mix gettext.mergedoesn't have this limit: its ownTask.async_streamusestimeout: :infinity(lib/mix/tasks/gettext.merge.ex:213). Runningmix gettext.extract && mix gettext.merge priv/gettextworks fine on the same project. Having the ceiling only on the combined flag seems unintentional.Would you take a PR that makes the timeout configurable, say via the project's
:gettextconfig or a--merge-timeoutflag, keeping 120s as the default? Failing that, even a note in the task docs pointing at the two-step workaround would help the next person who hits this.