You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed an issue in an application I am currently writing, where if the stack trace (Elmah.Error.Detail) is overly large the exception will silently fail with a 400 Bad Request error when being persisted to table storage.
I believe this is due to the 64 KB column limit on table storage, as if I substring the Elmah.Error.Detail property to 5000 characters the exception gets logged (unmodified, the Elmah.Error.Detail is about 10000 chars).
I've added this check (and substring) in AzureTableStorageErrorLog.Log(Error error), but it's clearly a bit of a hack.
Any ideas? I have a unit test that'll show the problem, I'm happy to upload to a public repo and link to it.
The text was updated successfully, but these errors were encountered:
I've noticed an issue in an application I am currently writing, where if the stack trace (Elmah.Error.Detail) is overly large the exception will silently fail with a 400 Bad Request error when being persisted to table storage.
I believe this is due to the 64 KB column limit on table storage, as if I substring the Elmah.Error.Detail property to 5000 characters the exception gets logged (unmodified, the Elmah.Error.Detail is about 10000 chars).
I've added this check (and substring) in AzureTableStorageErrorLog.Log(Error error), but it's clearly a bit of a hack.
Any ideas? I have a unit test that'll show the problem, I'm happy to upload to a public repo and link to it.
The text was updated successfully, but these errors were encountered: