Problem
GFQL call validation has parity and depth gaps for encoding operations used in downstream remote flows.
Findings (audit date: 2026-04-29)
1) Missing encoding operations in call safelist
In graphistry/compute/gfql/call/validation.py safelist entries include:
encode_point_color
encode_edge_color
encode_point_size
encode_point_icon
But no safelist entries for:
encode_edge_icon
encode_axis
At the same time, Plottable exposes both methods (encode_edge_icon, encode_axis).
2) Typing contract mirrors the same omission
graphistry/models/gfql/types/call.py CallMethodName also excludes encode_edge_icon and encode_axis, reinforcing runtime/type-level mismatch.
3) Existing encoding validation is shallow
For present encode ops, validators often only check container type (e.g., categorical_mapping: is_dict, palette: list) without key/value semantic checks.
Why this matters
- Downstream tools using GFQL calls for remote execution get inconsistent capabilities vs direct Plottable APIs.
- LLM/tooling flows need clear, early, actionable validation errors for encoding payload mistakes.
- Current mismatch can push users toward ad-hoc settings-level workarounds.
Requested behavior
- Decide and document parity policy:
- either add
encode_edge_icon and encode_axis to GFQL call safelist + typed call model, or
- explicitly document they are intentionally unsupported in call mode.
-
If supported, add validators + executor support + tests for both ops.
-
Improve encode validator depth for common payloads:
categorical_mapping key/value type checks
palette entry type checks
- clear per-field error messages
Related
Problem
GFQL call validation has parity and depth gaps for encoding operations used in downstream remote flows.
Findings (audit date: 2026-04-29)
1) Missing encoding operations in call safelist
In
graphistry/compute/gfql/call/validation.pysafelist entries include:encode_point_colorencode_edge_colorencode_point_sizeencode_point_iconBut no safelist entries for:
encode_edge_iconencode_axisAt the same time, Plottable exposes both methods (
encode_edge_icon,encode_axis).2) Typing contract mirrors the same omission
graphistry/models/gfql/types/call.pyCallMethodNamealso excludesencode_edge_iconandencode_axis, reinforcing runtime/type-level mismatch.3) Existing encoding validation is shallow
For present encode ops, validators often only check container type (e.g.,
categorical_mapping: is_dict,palette: list) without key/value semantic checks.Why this matters
Requested behavior
encode_edge_iconandencode_axisto GFQL call safelist + typed call model, orIf supported, add validators + executor support + tests for both ops.
Improve encode validator depth for common payloads:
categorical_mappingkey/value type checkspaletteentry type checksRelated