Hi
We are experiencing an issue where exceptions are not being properly logged with their full details to Application Insights.
Problem: When an error occurs, we only see a generic error message in the logs, not the actual exception details or stack trace.
Example from Application Insights:
MessageTemplate: ---------- RemoteServiceErrorInfo ----------
{
"code": null,
"message": "Sisäinen virhe tapahtui pyynnön käsittelyssä.",
"details": null,
"data": null,
"validationErrors": null
}
RequestPath: /api/abp/application-localization
ActionName: Volo.Abp.AspNetCore.Mvc.ApplicationConfigurations.AbpApplicationLocalizationController.GetAsync (Volo.Abp.AspNetCore.Mvc)
Expected behavior: We want to hide exception details from the client (for security), but still log the full exception with stack trace to Application Insights for debugging purposes.
Questions:
IExceptionFilter or override IExceptionToErrorInfoConverter?Multitenancy to Elsa workflows to be able to separate workflows for each tenant.
That was the correct one, thanks!
The AI bot answer is wrong. There is no key "PhoneNumberConfirmed" in the en.json file either. I know I can add it myself, but what is the key?
Where is this key defined. I did not find it from anywhere. The field is for "phone number confirmed" and language is finnish (fi-FI)
Hello, We will try Mailkit. I think Abp should move away from using the default smtp email sending service since the smtp client is clearly not meant to be used this way.
Hi,
We have an ABP Framework applications running on Azure App Services. E-mail is sent via SendGrid SMTP.
Issue After the app has been running for a while, outgoing e-mails stop being sent. Nothing appears in our SendGrid activity log, so the messages never reach SendGrid. Restarting our two web apps (API host and Auth server) immediately restores e-mail delivery, but the problem reappears after some days of uptime.
Could you suggest what might cause this and what to check next?
That actually was my initial assumption, that it tries to receive the data from the database and the database query is actually the slowing factor here, but looking at our azure monitoring, there is no dependency to database so the execution does not (at least every time) go through the database.
I guess this has to be related to Redis somehow, but not in the way you described, if I understood correctly
Yes, we are using Redis already. My initial thought was that it cannot be the Redis, since we see no overload indicators in Azure Redis monitoring. However we see some intermittent timeout exceptions and in those I can see, if I understand correctly, some pretty high number of waiting calls (async-ops count), which could indicate some Redis overload.
Timeout awaiting response (outbound=0KiB, inbound=0KiB, 5859ms elapsed, timeout is 5000ms), command=EXPIRE, next: EXPIRE c:Volo.Abp.MultiTenancy.TenantConfiguration,k:SCM_PROD:i:dba2a1ba-5a58-f4f6-ec6a-3a03f2c223b2,n:null, inst: 0, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: DequeueResult, ws: Idle, in: 0, last-in: 0, cur-in: 63, sync-ops: 19115, **async-ops: 1215359**, serverEndpoint: redis-paas-PROD-002.redis.cache.windows.net:6380, conn-sec: 27571.89, aoc: 0, mc: 1/1/0, mgr: 9 of 10 available, clientName: AW0SDWK000002(SE.Redis-v2.7.27.49176), IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=30,Free=32737,Min=2,Max=32767), POOL: (Threads=30,QueuedItems=4,CompletedItems=3836531,Timers=54), v: 2.7.27.49176 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)
We have a very serious issue in our production environment where the above mentioned queries have started to take a lot of time. Somethimes they work fast but quite often they take several minutes. Other features of our application work smoothly so overall resource constrictions have been ruled out. Now we need help from you on how to dissect this problem since this is pure Abp code.
