dotnet/orleans · error · ArgumentException

Key length {0} is too long to be an DynamoDB row key. Key={1

Error message

Key length {0} is too long to be an DynamoDB row key. Key={1}

What it means

Thrown by AWSUtils.ValidateDynamoDBRowKey when the supplied row (sort) key string is 1024 characters or longer. DynamoDB limits a sort key attribute to 1024 bytes (UTF-8); this guard rejects oversized sort keys up front with a message reporting the length and the key value.

Source

Thrown at src/AWS/Shared/AWSUtils.cs:58

        /// <param name="key"></param>
        /// <returns></returns>
        public static string ValidateDynamoDBPartitionKey(string key)
        {
            if (key.Length >= 2048)
                throw new ArgumentException(string.Format("Key length {0} is too long to be an DynamoDB partition key. Key={1}", key.Length, key));

            return key;
        }

        /// <summary>
        /// Validate DynamoDB RowKey.
        /// </summary>
        /// <param name="key"></param>
        /// <returns></returns>
        public static string ValidateDynamoDBRowKey(string key)
        {
            if (key.Length >= 1024)
                throw new ArgumentException(string.Format("Key length {0} is too long to be an DynamoDB row key. Key={1}", key.Length, key));

            return key;
        }
    }
}

View on GitHub (pinned to fca799fa70)

Solutions

  1. Shorten the components that make up the row key and keep only what is needed for ordering/identity.
  2. If a long value must be encoded, hash it to a fixed width and store the original in a separate attribute.
  3. Review the row-key construction in your provider usage and remove redundant segments.
  4. Keep the composed key well under 1024 bytes to allow for multi-byte UTF-8 characters.

Example fix

// before: row key embeds a long transaction id + timestamp + label
string rowKey = $"{txId}_{timestamp}_{longLabel}"; // may exceed 1024

// after: keep row key compact, store extras as attributes
string rowKey = $"{timestamp:D20}_{txIdHash}";
Defensive patterns

Strategy: validation

Validate before calling

string SafeRowKey(string raw)
{
    if (string.IsNullOrEmpty(raw) || raw.Length >= 1024)
        return Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes(raw ?? Guid.NewGuid().ToString())));
    return raw;
}

Type guard

static bool IsValidRowKey(string key) => !string.IsNullOrEmpty(key) && key.Length < 1024;

Try / catch

try { AWSUtils.ValidateDynamoDBRowKey(key); }
catch (ArgumentException ax) when (ax.Message.Contains("row key"))
{
    key = Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes(key)));
}

Prevention

When it happens

Trigger: Produced wherever a DynamoDB row/sort key is built and validated (transactional state row keys, persistence row keys). Triggered when the composed row key — often a sequence-id-prefixed or transaction-id-prefixed string — exceeds 1024 chars, or when a custom row-key scheme packs too much into the sort key.

Common situations: Custom row-key formatting that embeds transaction ids, timestamps, or long identifiers; a fork that changed the row-key layout to include extra fields; very long state names or sequence prefixes concatenated into the row key.

Related errors


AI-assisted analysis of dotnet/orleans@fca799fa70 (2026-08-13). Data as JSON: /api/errors/81048039d2ed61be. Report an issue: GitHub.