Activities of "neethucp"

The Microsoft.Azure.StackExchangeRedis package supports authentication via Managed Identity. Is there a way to override ABP.IO’s default cache connection configuration to leverage this package and connect securely to Azure Redis?

Hi,

Our application is deployed in Azure, and we’d like to connect to both Azure Redis Cache and Azure Service Bus using Managed Identity for secure, secretless authentication. Does ABP.IO provide built-in support or configuration options for this scenario? If not, could you please guide us on how to implement this integration within an ABP.IO application?

So how can we test this in our microservice project? Do we need to upgrade the packages to v9.3?

Hi, we’ve tested this in the sample project and it’s working as expected. However, in our main project, we don’t have a HandleSelector configured, and setting it up might be difficult due to the number of events and the fact that our event handlers are in a separate project. The handlers also persist data to both Entity Framework and MongoDB. Is there an alternative way to test this setup without configuring HandleSelector?

Also, we’re wondering about error handling:

• If an event handler throws an exception, will the system keep retrying indefinitely?
• Is there a way to mark the event as failed after a maximum number of retries?
• And will a failed event block subsequent events from being processed?

Hi,

Processed is getting set to true for us every time, it is not even invoking the handler. https://streamable.com/4wmglj

Hi, I have sent you the debug logs. Can you please check?

Hi, We have events coming from different microservices. So, if the events are not received in the correct order, it throws foreign key exception when inserting to db. await _repository.InsertAsync(appLicence);

Hi,

Please find below the event handler code. _repository stores data to SQL Server Db. _eventHistoryRepository stores data to mongo db.

We tried adding a try catch here and set the MarkAsProcessed only if there is no exception.

We're currently implementing the Inbox pattern in our microservice architecture and have run into an issue with the Processed flag in the AbpEventInbox table. When an event is received, our service performs two operations:

• Synchronizes data to a SQL Server database
• Stores event details in MongoDB We have two DbContexts within the same microservice, with the AbpEventInbox table configured in the SQL Server context

The problem is that the Processed flag is being set to true even when an exception is thrown during event handling. This results in the event being marked as processed, despite not being successfully handled.

We attempted to override the InboxProcessor and invoke MarkAsProcessedAsync only when no exception occurs. However, we noticed another issue: sometimes the Processed flag is still being set to true even though the event handler was never invoked.

Here’s a snippet from our logs:

[10:48:52 DBG] No events found in the inbox.

The insert statement is logged, but the subsequent select query doesn’t return any events, even though the Processed flag was explicitly set to false. The event is set to processed somehow without being logged.

We want to ensure that:

• Events are only marked as processed if they are successfully handled.
• Failed events due to exceptions are retried.

Could you guide us on how to reliably prevent premature flagging and ensure retry logic works as expected?