Handle exported-function failures without crashing logging cleanup

[Copilot]

logging.sh could emit Bash internals errors when the original failure came from an exported/external function. Instead of logging the failure cleanly, the fatal path could recurse into pop_var_context: head of shell_variables not a function context.

• Root cause

  • fatal() cleaned up child jobs with a jobs -p | xargs kill pipeline.
  • In the exported-function error path, that cleanup command could itself trip Bash’s function-context handling and mask the original failure.

• Change

  • Replaced the cleanup pipeline with guarded, Bash-native PID collection and termination.
  • Child PIDs are read into an array first; kill is only invoked when the array is non-empty.
  • Cleanup failures are explicitly ignored so logging preserves the original error path.

• Behavior

  • Failures originating from exported functions now log normally instead of crashing inside Bash internals.
  • Existing child-process cleanup behavior is preserved for normal fatal exits.

# before
jobs -p | xargs 'kill -9 --' 2>/dev/null

# after
local -a CHILD_PIDS=()
mapfile -t CHILD_PIDS < <(jobs -p 2>/dev/null || true)
if (( "${#CHILD_PIDS[@]}" )); then
    kill -9 -- "${CHILD_PIDS[@]}" 2>/dev/null || true
fi

[pirate]

@copilot how does this actually fix the problem the user reported? this seems like an unrelated change? or am I misunderstanding?

[Copilot]

@copilot how does this actually fix the problem the user reported? this seems like an unrelated change? or am I misunderstanding?

Yes — I verified the failure is already on the existing ERR -> log_quit -> fatal path, and the extra pop_var_context comes from fatal()'s child-cleanup line, not from the exported function body itself. Using the same exported-function repro against HEAD~1 vs 0ceef7b: HEAD~1 logs [FATAL] environment:0 external_fail() 1 and then hits pop_var_context, while 0ceef7b logs the same fatal message without the Bash internal error. So the change is related because it removes the crashing step in the logging path that only shows up when the original failure came from an exported environment function.

[cubic-dev-ai]

No issues found across 1 file