amber/src/main/scala/org/apache/texera/workflow/LogicalLink.scala is the case class describing an edge in the user-facing logical workflow graph. It has two construction paths and ships across the wire / persisted in saved workflows, but it has no unit test today:
| Surface |
Need to pin |
| Primary constructor |
(OperatorIdentity, PortIdentity, OperatorIdentity, PortIdentity) round-trips into the four fields. |
Secondary @JsonCreator constructor |
(String, PortIdentity, String, PortIdentity) wraps each string in OperatorIdentity(...) — this is the Jackson deserialization path, used to read user-saved workflow JSON. |
Case-class equals / hashCode |
Structural equality across the four fields. |
| Jackson deserialization (single-direction) |
objectMapper.treeToValue from a JSON object with raw-string fromOpId / toOpId (the shape user-saved workflows actually have) deserializes correctly via the @JsonCreator String overload. Note: full writeValueAsString → readValue round-trip is currently not supported — writeValueAsString emits OperatorIdentity as {"id":"op-A"} (object form), but the @JsonCreator String overload Jackson dispatches to on read can't accept an object. The spec characterizes this asymmetry rather than asserting a passing round-trip; a follow-up fix (additional @JsonCreator object overload or a custom @JsonDeserialize) would flip the characterization-pin into a real round-trip. |
| Field-name pins |
fromOpId / toOpId are pinned by @JsonProperty annotations; fromPortId / toPortId derive from Scala parameter names (no annotation). Both are pinned so a Scala-side rename can't silently break saved workflows. |
| Missing-field default behavior |
Pin the current "no validation in the @JsonCreator path" — missing op-id fields silently produce OperatorIdentity(null) instead of throwing; a future hardening should fail this on purpose. |
Priority
P3 - Low
Task Type
amber/src/main/scala/org/apache/texera/workflow/LogicalLink.scalais the case class describing an edge in the user-facing logical workflow graph. It has two construction paths and ships across the wire / persisted in saved workflows, but it has no unit test today:(OperatorIdentity, PortIdentity, OperatorIdentity, PortIdentity)round-trips into the four fields.@JsonCreatorconstructor(String, PortIdentity, String, PortIdentity)wraps each string inOperatorIdentity(...)— this is the Jackson deserialization path, used to read user-saved workflow JSON.equals/hashCodeobjectMapper.treeToValuefrom a JSON object with raw-stringfromOpId/toOpId(the shape user-saved workflows actually have) deserializes correctly via the@JsonCreatorString overload. Note: fullwriteValueAsString→readValueround-trip is currently not supported —writeValueAsStringemits OperatorIdentity as{"id":"op-A"}(object form), but the@JsonCreatorString overload Jackson dispatches to on read can't accept an object. The spec characterizes this asymmetry rather than asserting a passing round-trip; a follow-up fix (additional@JsonCreatorobject overload or a custom@JsonDeserialize) would flip the characterization-pin into a real round-trip.fromOpId/toOpIdare pinned by@JsonPropertyannotations;fromPortId/toPortIdderive from Scala parameter names (no annotation). Both are pinned so a Scala-side rename can't silently break saved workflows.@JsonCreatorpath" — missing op-id fields silently produceOperatorIdentity(null)instead of throwing; a future hardening should fail this on purpose.Priority
P3 - Low
Task Type