Azure / Azure/azure-functions-dotnet-worker

TableInput without PartitionKey for an IEnumerable for a custom ITableEntity type fails after update of Microsoft.Azure.Functions.Worker.Extensions.Tables from 1.4.3 to 1.5.0

Open
#3,107 0 comments 0 reactions 0 assignees View on GitHub
extensions: azure-tables needs-investigation potential-bug
Dominant language
C#
Stars
466
Forks
215
Avg merge
3d 10h
Merged PRs (30d)
7

Description

### Description

After an update of Microsoft.Azure.Functions.Worker.Extensions.Tables from 1.4.3 to 1.5.0, execution of an existing function with a TableInput annotation that should fetch the whole table and thus has no PartitionKey specified started to throw an unexpected ArgumentNullException for the PartitionKey argument.

After reducing the problem as far as possible locally, the sample code below illustrates the problem.
With 1.4.3, both functions work as expected. With 1.5.0, the TestTableInputCustomTableEntity function can't be executed due to the ArgumentNullException being thrown:

```
Microsoft.Azure.Functions.Worker.FunctionInputConverterException: "Error converting 1 input parameters for Function 'TestTableInputCustomTableEntity': Cannot convert input parameter 'tableEntries' to type 'System.Collections.Generic.IEnumerable`1[[Test.Models.CustomTableEntity, Test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]' from type 'Microsoft.Azure.Functions.Worker.Grpc.Messages.GrpcModelBindingData'. Error:System.ArgumentNullException: Value cannot be null. (Parameter 'PartitionKey')
at Microsoft.Azure.Functions.Worker.Extensions.Tables.TypeConverters.TableConverterBase`1.ThrowIfNullOrEmpty(String value, String nameOfValue) in /_/extensions/Worker.Extensions.Tables/src/TypeConverters/TableConverterBase.cs:line 74
at Microsoft.Azure.Functions.Worker.Extensions.Tables.TypeConverters.TablePocoConverter.ConvertModelBindingDataAsync(TableData content, Type targetType) in /_/extensions/Worker.Extensions.Tables/src/TypeConverters/TablePocoConverter.cs:line 69
at Microsoft.Azure.Functions.Worker.Extensions.Tables.TypeConverters.TablePocoConverter.ConvertAsync(ConverterContext context) in /_/extensions/Worker.Extensions.Tables/src/TypeConverters/TablePocoConverter.cs:line 46"

```

```[Function(nameof(TestTableInputCustomTableEntity))]
public async Task TestTableInputCustomTableEntity([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req,
[TableInput(Constants.TableName, Connection = "AzureWebJobsStorage")] IEnumerable tableEntries)
{
foreach (var item in tableEntries)
{
_logger.LogInformation($"Timestamp: {item.Timestamp}, Integer: {item.Integer}");
}

return true;
}

[Function(nameof(TestTableInputTableEntity))]
public async Task TestTableInputTableEntity([HttpTrigger(AuthorizationLevel.Function, "post")] HttpRequestData req,
[TableInput(Constants.TableName, Connection = "AzureWebJobsStorage")] IEnumerable tableEntries)
{
foreach (var item in tableEntries)
{
_logger.LogInformation($"Timestamp: {item.Timestamp}");
}

return true;
}```

### Steps to reproduce

1. Trigger a function using the TableInput annotation without a specified PartitionKey for an IEnumerable with a custom ITableEntity type.
2. Observe the unexpected ArgumentNullException for the PartitionKey argument, which was not encountered with 1.4.3.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by comparing the conversion path in extensions/Worker.Extensions.Tables/src/TypeConverters/TableConverterBase.cs and TablePocoConverter.cs between versions 1.4.3 and 1.5.0. Reproduce the two IEnumerable TableInput functions without a PartitionKey, then verify that custom ITableEntity enumeration works while the existing TableEntity case remains working without the ArgumentNullException.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, csharp
Domain
backend, databases
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.