Hi,
Please find below the event handler code. _repository stores data to SQL Server Db. _eventHistoryRepository stores data to mongo db.
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:
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:
Could you guide us on how to reliably prevent premature flagging and ensure retry logic works as expected?
Hi, We don't have access to Azure Application gateway logs, it's in client environment, we are not getting any logs in blazor server application, it's not even reaching blazor server application.
How is this handled in abp generated projects? Is it better to issue reference token or store the token in cache? We also have the issue of menu items getting cleared when token expires when the application is idle for some time and user returns.
Hi, We tried to refresh the token in blazor server as mentioned here. But this is resulting in cookie size to be huge and is blocked by the app gateway. Is there a better way to handle this?
I really appreciate your swift reply! Is there a scheduled timeline for its release?
But I don't want to update task type when task item is inserted or modified as TaskType is an AggregateRoot. I believe the concurrency stamp and modification time of an aggregate root should not be updated when a related aggregate root changes.
This adjustment would be reasonable if the child entity were an AuditedEntity. For instance, in the case of an Order and Order Items, it might be necessary to update the modification time and concurrency stamp of the Order when an Order Item is inserted or modified. In such scenarios, I would extend OrderItem from AuditedEntity rather than AuditedAggregateRoot.
I believe this is a bug with abp code.
We tried the following code to ignore all entites.
Configure<AbpEntityChangeOptions>(options => { options.IgnoredNavigationEntitySelectors.Add("DisableAllEntity", _ => true); });
Do you think this could have any unintended consequences?