Altinn / Altinn/app-lib-dotnet

Reliability issues for Altinn Events integration

Open
#1,081 1 comment 0 reactions 0 assignees View on GitHub
kind/bug
Dominant language
C#
Stars
8
Forks
27
Avg merge
1h 21m
Merged PRs (30d)
7

Description

### Description of the bug

Service owners create reciever systems to download completed/archived instances to their systems. There are 2 flavors:

* Poll-based - poll archived instances through the Storage API
* Events-based - recieve events from Altinn Events (we publish `app.instance.process.completed` from the app, if `RegisterEventsWithEventsComponent` is enabled)

Previously there were reliability issues in both of these approaches. Committing the process state and instance events (which reciever systems rely on to be in sync) were 2 separate requests from the proces engine in the app and therefore two separate DB transactions in Storage (2pc). This was fixed in the v8.5 release of the app: https://github.com/Altinn/altinn-storage/issues/544

The events-based approach however is using a separate Altinn API/service (Altinn Events), which makes it harder to fix. Options:

* Fix the process engine. There is a larger project planned for 2025 where the aim is to address all reliability issues in the process engine. We can rarely rely on Storage to give us transactionality and reliability as the process definition for an instance may use a variety of external APIs to drive the instance process forward. So it is a hard requirement for the process engine to be able to drive itself forward reliably.
* Extend Storage with outbox pattern or similar. The Storage DB already serves as the "source of truth" in terms of the state of the instances, so we could add outbox events as part of the larger transaction implemented in the previous Storage PR: https://github.com/Altinn/altinn-storage/issues/544. It is easier to do in isolation, but could be viewed as temporary

As of Febuary 2025 we have had monitoring and active mitigations in place to resend Altinn Events when that has failed within the app.

Currently it seems the best way to create a receiver system is a hybrid of the aforementioned approaches
* Use Altinn Events by subscribing to `app.instance.process.completed` and enabling `RegisterEventsWithEventsComponent` in the app
* Periodically (e.g. daily) poll for missed instances, since Altinn Events does not retry forever

### Steps To Reproduce

1. Complete instance

### Additional Information

_No response_

Contributor guide

Open the contributing guide

Research direction

No source file or test is named. Start by reviewing the process-completion path, the RegisterEventsWithEventsComponent setting, and the app.instance.process.completed event flow; compare the proposed process-engine and Storage outbox approaches, with issue 544 as context. Done requires an agreed reliability fix rather than the current hybrid mitigation.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
api, backend, distributed-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.