[TF-11813] do not colorize runHeader when returned as err

[laurenolivia]

Fixes #

We should not call colorize on strings that are returned as error messages.

Target Release

1.5.x

Draft CHANGELOG entry

NEW FEATURES | UPGRADE NOTES | ENHANCEMENTS | BUG FIXES | EXPERIMENTS

• Fix terminal error by removing colorized text

Before

After

[brandonc]

❔ 👇

[brandonc]

There are some peculiar things about this error that I feel compelled to point out that make this bug fix a little less than straightforward.

We are colorizing (that is, replace [color] codes with terminal escape sequences that produce color in a terminal) the text of an error message and returning it as an error type.

The original intent of the error diagnostics are to basically format errors like this:

Specifically, a red bar prefixing a red label "Error:", followed by a white summary, followed by gray details.

By injecting escape codes into the details, we're hacking the error and overriding the intend of the diagnostics output.

If this error were instead used in JSON output, or just logged, or anything other than being displayed in the terminal, the escape characters wouldn't make sense and it would come out like { "error": { "details": "\x1b[1;33mTo view this run in a browser,..." }}

Maybe a better solution is to return an error message that does not "hack" the terminal, which may mean using a string that is not runHeader

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

[laurenolivia]

changelog added via #34715