Unable to get table reference or create table. Aborting write operation.

[Mikkelcv]

Previous function runtime: 4.1037.1.23605
Current function runtime: 4.1038.300.25164

After the function runtime version has been updated to 4.1038 then our function app periodicaly every 10 minutes reports the exception:

"Unable to get table reference or create table. Aborting write operation."

Message:

This request is not authorized to perform this operation using this permission.
Time:2025-04-11T11:38:55.5555894Z
Status: 403 (Forbidden)
ErrorCode: AuthorizationPermissionMismatch

The execption originates in:
{"assembly":"Microsoft.Azure.WebJobs.Script.WebHost, Version=4.1038.0.0, Culture=neutral, PublicKeyToken=null","method":"Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository+<FlushLogs>d__30.MoveNext","level":34,"line":195,"fileName":"/_/src/WebJobs.Script.WebHost/Diagnostics/DiagnosticEventTableStorageRepository.cs"}

Granting the function app: "StorageTableDataContributor" RBAC role on the storage enables the function app to create an empty table in the storage.

Why is it now a requirement that this empty table must be created?
How do we disable this so we can have the old functionallity back?

It is NOT an option to grant this RBAC role to all function apps, we do not need this and wont grant access that is not required otherwise.

The guide:
https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations?tabs=azure-cli

Does not explain that the access is required. Is it something that is on its way?

[asos-chanhkiethuynh]

We have been experiencing the same issue as well out of no where, since 26/04/2025.

[scrocquesel-ml150]

Neither is https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference?tabs=blob&pivots=programming-language-csharp#connecting-to-host-storage-with-an-identity updated.
This is related to modification done for #9569

[scrocquesel-ml150]

The role "Storage Table Data Contributor" on the storage account is enough.

[rob-thijssen]

I totally agree on all statements made by @Mikkelcv. Especially on this one:
It is NOT an option to grant this RBAC role to all function apps, we do not need this and wont grant access that is not required otherwise.

We're also experiencing this issue since april 11th, and our logs are already polluted with these messages for multiple subscriptions.
As a work-around we could add this statement: "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository": "None" to host.json in the logging/loglevel section. But for obvious reasons this is not the desired solution.
So could this please be fixed in a decent manner asap?

[WingTai]

We have also been experiencing this issue since around March 26th, with an increase in these errors since April 11th, even though we haven't deployed any new versions of the affected function apps in long time.

Any acknowledgement and fix from MSFT? Preferably would not like to apply the suggested workarounds.

[arjavgarg]

Yes, we also started seeing this issue on 3/26/2025, 9:25:43.665 AM (UTC)

[czeslav87]

+1

Multiple function apps, using Managed Identity access to storage with Storage Blob permissions only, started to throw this on 26th March 2025.

[LavanyaMullapudi2328]

Role assignment is not helping out. Still seeing the error even after assigning the "Storage Table Data Contributor " Role to the function app

[jviau]

This is a diagnostic feature running in the background. These failures are not impactful to the health of the app. There is a PR up to improve these logs.

For the time being you can add a log filter for Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository to host.json and filter out logs.

You can also disable this feature via an app setting: AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging

AzureWebJobsFeatureFlags is a comma separated list of values, so if you have other values append this with a comma separator.

https://learn.microsoft.com/azure/azure-functions/functions-app-settings#azurewebjobsfeatureflags

[nzthiago]

@jviau if this exception is landing on customers' App Insights are we unnecessarily inflating their app insights (cost implications)?

[jviau]

@nzthiago the workarounds I provided will prevent it from going to app insights. The linked PR by @cjaliaga (#10996) will also greatly reduce the volume of telemetry emitted here. The diagnostic events feature will self-disable in this scenario (no permissions)

[nzthiago]

Aha - thank you, it's that linked PR I missed so that customers don't need any workaround.

[thenecroscope]

This is a diagnostic feature running in the background. These failures are not impactful to the health of the app. There is a PR up to improve these logs.

For the time being you can add a log filter for Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository to host.json and filter out logs.

You can also disable this feature via an app setting: AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging

AzureWebJobsFeatureFlags is a comma separated list of values, so if you have other values append this with a comma separator.

https://learn.microsoft.com/azure/azure-functions/functions-app-settings#azurewebjobsfeatureflags

This almost works for us. One question please
Can we combine both of these, for example;

AzureWebJobsFeatureFlags=DisableDiagnosticEventTableStorageRepository

I would prefer to handle the filtering at the Environment variable level if possible as we have so many function apps to update.

Many thanks,

[seilorjunior]

I am also seeing this issue with my customer, we gave the role in the storage, but we are still having the exceptions.

[thenecroscope]

I tried several environment setting / variables but no luck so far:

AzureFunctionsJobHost__logging__logLevel__Azure.Data.Tables = None
AzureFunctionsJobHost__logging__logLevel__Microsoft.Azure.WebJobs.Extensions.Tables = None
Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository = None

I think this approach may have worked, but it goes over the 100 character variable limit, so that failed also.
AzureFunctionsJobHost__logging__logLevel__Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository = None

[thenecroscope]

I tried to rollback to the previous Image using:

FUNCTIONS_EXTENSION_VERSION = 4.1037.1 (plus a few different combinations)
This appears not work on an EP1 Linux plan running dotnet-isolated 8.0

Weirdly when I set the version to 1.37.1, it downloads image 4.1037.1, not sure why this is|

I cant work out the correct way to pin to a specific image.

[Qaizer]

@jviau
Will this AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging have any other implications?

[thenecroscope]

@jviau Will this AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging have any other implications?

For us this is not really a viable option unfortunately, as this will disable all logging and ideally we only want to disable Table logs for example

[jviau]

AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging will only impact table logs. Logs to application insights, open telemetry, and azure monitor will not be affected.

[scrocquesel-ml150]

Could we have some documentation on this diagnostic feature ? I have functions using classic connectionString with those table logs. Didn't pay attention to them until now. Is this an old feature ? What are the Microsoft recommandation, should it be disabled by default ?