prestodb/presto · error · ParseError

{parse_error} ConnectorTransactionHandle ConnectorTransacti

Error message

{parse_error} ConnectorTransactionHandle  ConnectorTransactionHandle

What it means

from_json for std::shared_ptr<ConnectorTransactionHandle> reads the subclass discriminator with getSubclassKey(j); a json::parse_error there is rethrown as ParseError(e.what() + " ConnectorTransactionHandle ConnectorTransactionHandle"). The error is raised while identifying which concrete transaction handle to construct, so the payload failed JSON parsing or lacks the '@type' discriminator before dispatch.

Source

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

void to_json(json& j, const std::shared_ptr<ConnectorTransactionHandle>& p) {
  if (p == nullptr) {
    return;
  }
  String type = p->_type;

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

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

  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<RemoteTransactionHandle>();
    j.get_to(*k);

View on GitHub (pinned to 55bb57d202)

Solutions

1. Read the embedded json::parse_error message (e.what()) for the precise syntax problem and offset.
2. Validate the JSON is an object containing '@type' before calling from_json.
3. Re-acquire or re-request the transaction payload if it was corrupted or truncated in transit.
4. Ensure coordinator and native worker are version-aligned so the discriminator contract matches.

Example fix

// before: trusting any JSON blob as a transaction handle
// from_json(j, txnHandle);
// after: pre-validate
// if (!j.is_object() || !j.contains("@type")) throw std::invalid_argument("missing @type for ConnectorTransactionHandle");
// from_json(j, txnHandle);

// Validate transaction handle payload before from_json
bool isValidTransactionHandlePayload(const nlohmann::json& j) {
  return j.is_object() && j.contains("@type") && j["@type"].is_string();
}
// usage before calling from_json(j, txnHandle);

try {
  from_json(j, txnHandle);
} catch (const facebook::presto::protocol::ParseError& e) {
  LOG(ERROR) << "ConnectorTransactionHandle unparseable: " << e.what();
  // re-acquire the transaction payload
}

When it happens

Trigger: Calling from_json(json, std::shared_ptr<ConnectorTransactionHandle>&) with an invalid JSON document (syntax error, non-object value, missing '@type') — for example a session/transaction payload that was truncated or is actually an error response.

Common situations: Bad responses from the coordinator stored/forwarded as transaction handles; manually constructed test JSON missing '@type'; network truncation of the transaction section of a larger request; schema drift after upgrading the coordinator.

Related errors

• PlanNode PlanNode
• ConnectorTableHandle ConnectorTableHandle
• {parse_error} ExecutionWriterTarget ExecutionWriterTarget
• {parse_error} ConnectorSplit
• INVALID_ARGUMENTS

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