Dendrogram's Color Threshold crashes the operator for every non-empty value

[kz930]

What happened?

DendrogramOpDesc.createDendrogram interpolates the Color Threshold field straight into scipy's color_threshold argument. The field is an EncodableString, so what the template renders is a decode expression, and the value reaching scipy at run time is a Python string. scipy compares it against the linkage distances, which are float64, and numpy refuses. Every non-empty Color Threshold therefore fails, whatever is typed; leaving the field empty takes the color_threshold=None branch instead, which is why this has gone unnoticed.

Expected: a numeric threshold colours the clusters joined below that linkage distance.

Generated by generatePythonCode() for a threshold of 1.5 (MS41 is its base64):

fig = ff.create_dendrogram(data, labels=labels, color_threshold=self.decode_python_template('MS41'))

Executing that generated module unmodified — only the pytexera import seam stubbed, decode_python_template doing the real base64 decode — against a five-row frame crashes. With the field left empty the same flow emits color_threshold=None and produces the chart.

Straight against ff.create_dendrogram on plotly 5.24.1 and scipy 1.18.0, the pinned versions:

color_threshold	result
None — field empty	renders
'1.5' — string, what the operator emits today	UFuncTypeError
1.5 — number	renders
'default' — scipy's own 0.7 × max distance	renders

plotly passes the value through untouched, so a fix belongs on the Texera side. It should convert with Python's float() and fall back to the original string rather than casting unconditionally, so that "default" keeps working.

How to reproduce?

1. Chain any source carrying two numeric columns and a label column into Dendrogram.
2. Set Value X Column, Value Y Column and Labels.
3. Put 1.5 in Color Threshold and run — the operator fails with the error below.
4. Clear Color Threshold and run the same workflow — it succeeds.

Version/Branch

1.3.0-incubating-SNAPSHOT (main)

Relevant log output

UFuncTypeError: ufunc 'greater_equal' did not contain a loop with signature matching types
(<class 'numpy.dtypes.Float64DType'>, <class 'numpy.dtypes.StrDType'>) -> None

[kz930]

/take

[kz930]

Duplicate of #7232: same field, same cause — the value reaches scipy as a Python string because the field is an EncodableString — and the same fix. Closing in favour of #7232, which PR #7234 carries.