fix: escape HTML characters in config visualization

[zilto]

This follows #1200. The solution follows the suggestion of @MG-MW.

This problem is specific to config values. Instead of displaying their node_name and type, they display their node_name and value. In the function _get_node_label(), the type_string argument is actually the result of str(value).

Essentially, we use html.escape to encode unsafe characters ", &, <, > and the Graphviz engine will convert them back (e.g., the string lt&; is rendered as <). Inserting this safe string inside the f-string ensures a valid final string.

At the same time, we added truncation for the config value. Displaying values can quickly get messy when people pass pd.Series as config values. Escaping characters after truncations give as better results

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 132afaf in 34 seconds

More details

• Looked at 46 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. hamilton/graph.py:239

• Draft comment:
  Consider applying the MAX_STRING_LENGTH truncation logic consistently across the codebase where similar string handling is done to ensure uniformity.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The PR introduces a constant MAX_STRING_LENGTH to limit the length of the type_string before escaping it. This is a good practice to prevent overly long strings from cluttering the visualization. However, the truncation logic should be applied consistently across the codebase where similar string handling is done.

2. hamilton/graph.py:239

• Draft comment:
  The MAX_STRING_LENGTH constant is defined multiple times. Consider defining it once and reusing it to adhere to the DRY principle.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment seems to be incorrect because the diff only shows one definition of MAX_STRING_LENGTH. Without evidence of multiple definitions in the diff, the comment does not seem actionable or necessary.
  I might be missing the context from other parts of the codebase where MAX_STRING_LENGTH could be defined again, but based on the diff alone, there is no evidence of this.
  The task is to review the diff provided, and based on that, the comment does not seem to be valid. If there were multiple definitions, they should have been visible in the diff.
  The comment should be deleted because there is no evidence in the diff that MAX_STRING_LENGTH is defined multiple times.

Workflow ID: wflow_sW1t7kWyEwpZvzoy

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.