[bug] mask_otlp_headers.sh should ignore short ::add-mask:: values on GHES to prevent over-masking logs

[jaroslawgajewski]

Summary

On GitHub Enterprise Server, the OTLP header masking helper can emit ::add-mask:: commands for very short values.

When that happens, GHES may apply the mask too broadly and redact matching characters throughout subsequent log output. This makes logs hard to read and can corrupt unrelated diagnostic data such as model names, numeric values, error codes, and token usage summaries.

This appears to be a framework-level issue because the behavior comes from the shared OTLP masking helper rather than repository-specific workflow logic.

Expected behavior

The OTLP masking helper should only emit safe mask values, or otherwise normalize masking behavior so logs remain readable on both github.com and GHES.

Actual behavior

After the OTLP masking step runs, unrelated later log lines can become over-masked.

Examples of affected output categories:

• Model names
• Numeric values
• Error codes
• Token or cost summaries
• Identifiers printed later in the job

Reproduction

Framework-level reproduction

1. Run a workflow on GHES that includes the OTLP header masking helper.
2. Provide OTLP headers whose parsed values can include very short fragments.
3. Print normal diagnostic output after the masking helper runs.
4. Observe that unrelated later log content is partially replaced with ***.

Minimal GHES-level reproduction

This demonstrates the underlying masking behavior the helper can trigger:

- run: |
    echo "::add-mask::4"
    echo "claude-sonnet-4.5"
    echo "HTTP 401"
    echo "Effective tokens: 123456"

On affected GHES environments, later output may be over-masked even though only a single-character value was masked.

Proposed fix

In the OTLP masking helper, filter out mask values below a safe minimum length before emitting ::add-mask::.

A reasonable default would be to ignore values shorter than 4 characters, matching the safer behavior commonly expected on github.com.

Impact

This is primarily an operability and debugging issue:

• Token usage and diagnostic summaries become hard to read
• Error codes can be obscured
• Model identifiers can be corrupted in logs
• Troubleshooting on GHES becomes significantly harder

Environment

gh-aw version: 0.74.8