multica-ai/multica · error

file content for --%s is empty

Error message

file content for --%s is empty

What it means

The CLI was given a --description-file / --content-file style flag whose target file exists and is readable, but after trimming a single trailing newline its content is empty. The CLI refuses to substitute empty content for the flag because that would silently wipe or no-op the field. This is a fail-fast guard so an empty file is reported instead of silently posting an empty description.

Source

Thrown at server/cmd/multica/cmd_issue.go:82

			return "", false, fmt.Errorf("read stdin for --%s: %w", stdinFlag, err)
		}
		body := strings.TrimSuffix(string(data), "\n")
		if body == "" {
			return "", false, fmt.Errorf("stdin content for --%s is empty", stdinFlag)
		}
		return body, true, nil
	}
	if filePath != "" {
		if err := ensureFileFlagWithinWorkdir(cmd, fileFlag, flagName, filePath); err != nil {
			return "", false, err
		}
		data, err := os.ReadFile(filePath)
		if err != nil {
			return "", false, fmt.Errorf("read file for --%s: %w", fileFlag, err)
		}
		body := strings.TrimSuffix(string(data), "\n")
		if body == "" {
			return "", false, fmt.Errorf("file content for --%s is empty", fileFlag)
		}
		return body, true, nil
	}
	if inline == "" {
		return "", false, nil
	}
	return util.UnescapeBackslashEscapes(inline), true, nil
}

// ensureFileFlagWithinWorkdir fails closed when a --<name>-file path resolves
// outside the current working directory, unless --allow-external-file is set.
//
// Agent task workdirs are isolated per profile and per task; machine-shared
// scratch paths like /tmp are not. MUL-4252 traced a cross-environment context
// leak to exactly this gap: a quick-create run wrote its description to a fixed
// /tmp/desc.md, the write silently failed because a *different* environment's
// run had left a stale file there minutes earlier, and --description-file then
// fed that stale content into the new issue. Requiring the file to live under

View on GitHub (pinned to 2c0912b6ec)

Solutions

  1. Inspect the file (wc -c / cat -A) and fix the upstream step that was supposed to write the description so it produces real content.
  2. If the empty file is itself unexpected, regenerate it and re-run the command.
  3. If you intentionally have no content, drop the --*-file flag entirely instead of pointing it at an empty file.
  4. For trivial one-line content, use the inline flag (e.g. --description "text") instead of a file.

Example fix

# before
printf '' > desc.md
multica issue create --title "Fix login" --description-file desc.md
# after
printf 'Login fails when session expires.' > desc.md
multica issue create --title "Fix login" --description-file desc.md
Defensive patterns

Strategy: validation

Validate before calling

# before invoking:
[ -s "$DESC_FILE" ] || { echo "description file empty: $DESC_FILE" >&2; exit 1; }
# -s is true only for non-empty files; also catches the missing-file case early

Prevention

When it happens

Trigger: Running `multica issue create --description-file <path>` (or any *-file flag handled by this helper) where the file is 0 bytes or contains only a single newline. The path must already pass the workdir guard and os.ReadFile, so the file exists and is readable but body == "" after strings.TrimSuffix(data, "\n").

Common situations: Agent or script pipelines that write a description to a temp file and the upstream generator (editor, jq, another command) produced empty output; a heredoc that failed to capture anything; a truncated file from a killed process; a file containing only a blank line.

Related errors


AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/1a6828dd87c3e4fd. Report an issue: GitHub.