[BUG] TablesTypeBinder.TryGet throws ArgumentNullException on type mismatches for Int64 properties

[cassxw]

Library name and version

Azure.Data.Tables 12.8.x with Azure.Core 1.47.x (Azure.Core.dll file version: 1.4700.125.36505)

Describe the bug

When using TableClient.QueryAsync<T>() with a model containing an Int64 (long) property, the Azure SDK throws ArgumentNullException: Value cannot be null. (Parameter 's') when the table column contains values that don't match the expected type. This includes:

• When the table column was stored as a smaller numeric type (e.g. Int32, Int16) but the model expects Int64.
• When the table returns DBNull.Value for null values.
• Any type mismatch between the stored value and the model property type.

The same issue affects long? (nullable long) because the code path is identical.

Expected behavior

The SDK should handle type conversions gracefully, converting smaller numeric types to Int64 and handling DBNull.Value appropriately, rather than throwing an unhandled exception.

Actual behavior

The query fails with an unhandled ArgumentNullException when the SDK encounters a table row with a type mismatch (e.g. Int32 stored but Int64 expected, or DBNull.Value) in an Int64 column. The entire query fails and no data can be retrieved.

System.ArgumentNullException: Value cannot be null. (Parameter 's')
   at System.Int64.Parse(String s, IFormatProvider provider)
   at Azure.Data.Tables.TablesTypeBinder.TryGet[T](BoundMemberInfo memberInfo, IDictionary`2 source, T& value)
   at Azure.Core.TypeBinder`1.BoundMemberInfo`1.Deserialize(TExchange source, Object o, TypeBinder`1 binderImplementation)
   at Azure.Core.TypeBinder`1.BoundTypeInfo.Deserialize[T](TExchange source)
   at Azure.Data.Tables.DictionaryTableExtensions.ToTableEntity[T](IDictionary`2 entity, BoundTypeInfo typeInfo)
   at Azure.Data.Tables.DictionaryTableExtensions.ToTableEntityList[T](IReadOnlyList`1 entityList)
   at Azure.Data.Tables.TableClient.<>c__DisplayClass55_0`1.<<QueryAsync>b__0>d.MoveNext()

Reproduction Steps

// Model with non-nullable long - CRASHES when stored value is null
public class TestEntity : ITableEntity
{
    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public DateTimeOffset? Timestamp { get; set; }
    public ETag ETag { get; set; }
    public long Depth { get; set; }  // Crashes when table has different numeric type
}

// Model with nullable long? - ALSO CRASHES!
public class TestEntityNullable : ITableEntity
{
    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public DateTimeOffset? Timestamp { get; set; }
    public ETag ETag { get; set; }
    public long? Depth { get; set; }  // Still crashes!
}

// Usage that triggers the bug:
await foreach (var result in tableClient.QueryAsync<TestEntity>())
{
    // Never reached - crashes on first null value
}

Environment

• Hosting platform: Windows 10/11, Azure App Service
• IDE: Visual Studio 2022
• .NET: .NET 8.0

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist

//cc: @christothes @jorgerangel-msft

[github-actions]

🎯 Agentic Issue Triage

Summary: TablesTypeBinder.TryGet throws an ArgumentNullException when deserializing table rows that have null values in Int64 (long or long?) columns, causing the entire QueryAsync() operation to fail rather than returning default(long) or null.

📋 Issue Details

Package: Azure.Data.Tables 12.8.x with Azure.Core 1.47.x
Affected API: TablesTypeBinder.TryGet<T> → TableClient.QueryAsync<T>()
Scenarios:

• Querying a table with a non-nullable long property where some rows have a null value in that column
• Querying a table with a nullable long? property where some rows have a null value — same crash despite using a nullable type

Root ask: Fix TablesTypeBinder.TryGet to handle null values for Int64/Int64? properties gracefully: return 0 for non-nullable long and null for long?, without throwing an exception.

🔎 Debugging / Reproduction Notes

The stack trace points to System.Int64.Parse(String s, IFormatProvider provider) being called with a null string s. The underlying cause is that TablesTypeBinder.TryGet uses identical parsing logic for both long and long?, and neither path guards against a null source value before calling Int64.Parse.

Suggested investigation steps:

1. Locate TablesTypeBinder.TryGet<T> in sdk/tables/Azure.Data.Tables/src/ and inspect how long and long? cases extract and parse the dictionary value.
2. Check whether other numeric types (int, double, Guid, etc.) have the same null-guard gap, to fix them consistently.
3. Add a null check before Int64.Parse: for long return default(long), for long? return null.
4. Add a unit/integration test with a table entity containing a null Int64 column to prevent regression.

🏷️ Label Confidence

• Category: Client — The bug is in SDK deserialization code (TablesTypeBinder.TryGet), not in the Azure Tables service itself.
• Service: Tables — Explicitly references Azure.Data.Tables package and TableClient.
• Confidence: High — Package name is explicitly stated, the bug is clearly in the SDK client layer, and matches the label pattern seen in previous Tables issues (e.g., [BUG] Cannot filter on Timestamp using Azure.Data.Tables SDK (Cosmos backend) #32468, [FEATURE REQ] Support for Azure Active Directory (AAD) for TableClient backed by CosmosDB #24406).

Generated by Agentic Triage for issue #57802 · ◷