prestodb/presto · error · ParseError

{parse_error} ConnectorSplit

Error message

{parse_error} ConnectorSplit

What it means

from_json for std::shared_ptr<ConnectorSplit> starts by extracting the subclass discriminator via p->getSubclassKey(j); if nlohmann raises json::parse_error there (malformed JSON, non-object document, or missing '@type'), it rethrows ParseError(std::string(e.what()) + " ConnectorSplit"). Note the message only appends one type name (unlike some sibling messages), so the meaningful part is the nlohmann parse_error text at the front.

Source

Thrown at presto-native-execution/presto_cpp/presto_protocol/core/presto_protocol_core.cpp:2568

  String type = p->_type;

  if (type == "$remote") {
    j = *std::static_pointer_cast<RemoteSplit>(p);
    return;
  }
  if (type == "$empty") {
    j = *std::static_pointer_cast<EmptySplit>(p);
    return;
  }
  getConnectorProtocol(type).to_json(j, p);
}

void from_json(const json& j, std::shared_ptr<ConnectorSplit>& p) {
  String type;
  try {
    type = p->getSubclassKey(j);
  } catch (json::parse_error& e) {
    throw ParseError(std::string(e.what()) + " ConnectorSplit");
  }

  if (j.contains("customSerializedValue")) {
    VELOX_CHECK(
        !type.empty() && type[0] != '$',
        "Internal handle type '{}' should not have customSerializedValue",
        type);
    std::string binaryData = velox::encoding::Base64::decode(
        j["customSerializedValue"].get<std::string>());
    getConnectorProtocol(type).deserialize(binaryData, p);
    return;
  }

  if (type == "$remote") {
    auto k = std::make_shared<RemoteSplit>();
    j.get_to(*k);
    p = k;
    return;

View on GitHub (pinned to 55bb57d202)

Solutions

1. Read the leading json::parse_error text for the exact cause and byte offset.
2. Log the raw split JSON before deserialization and verify it is a complete object with '@type'.
3. Check transport integrity (HTTP status, content-length) and re-fetch corrupted payloads.
4. Validate/pre-parse the JSON (is_object + contains("@type")) before calling from_json.

Example fix

// before: from_json(splitJson, connectorSplit); // ParseError: syntax error at byte N
// after:
// if (!splitJson.is_object() || !splitJson.contains("@type")) throw std::invalid_argument("invalid ConnectorSplit json");
// from_json(splitJson, connectorSplit);

// Validate split payload before deserialization
bool isValidConnectorSplitPayload(const nlohmann::json& j) {
  return j.is_object() && j.contains("@type") && j["@type"].is_string();
}
// nlohmann::json j = nlohmann::json::parse(body, nullptr, false);
// if (j.is_discarded() || !isValidConnectorSplitPayload(j)) throw std::invalid_argument("bad connector split json");

try {
  from_json(j, connectorSplit);
} catch (const facebook::presto::protocol::ParseError& e) {
  LOG(ERROR) << "ConnectorSplit unparseable: " << e.what();
  // re-fetch the split payload and check transport integrity
}

When it happens

Trigger: Calling from_json(json, std::shared_ptr<ConnectorSplit>&) with input that fails JSON parsing before dispatch — e.g. a truncated split list from a stage's task description, a non-object JSON value, or a missing '@type' discriminator in the split payload.

Common situations: Large split payloads truncated in transit; coordinator error responses (HTML/JSON error) passed to the split deserializer; hand-built split fixtures missing '@type'; protocol/key-name drift between coordinator versions.

Related errors

• PlanNode PlanNode
• ConnectorTableHandle ConnectorTableHandle
• {parse_error} ConnectorTransactionHandle ConnectorTransacti
• {parse_error} ExecutionWriterTarget ExecutionWriterTarget
• no abstract type PlanNode

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/e1f731fc7374c062. Report an issue: GitHub.