Problem with ParticipantContextConfiguration not being restored after restart in 0.16.0

[alaguna-hiberuscom]

Hi team,

We are facing an issue with Identity Hub 0.16.0.

We developed a custom extension that initializes a participant during the first startup of Identity Hub. The extension creates the participant successfully and everything works correctly.

The problem appears after the server is restarted. Since the participant already exists, the extension skips the participant creation logic. However, after the restart, the ParticipantContextConfiguration is not loaded. As a consequence, when requesting an STS token, Identity Hub throws a 500 error because the ParticipantContextConfiguration is empty.

Current behavior

First startup:

Participant is created successfully
ParticipantContextConfiguration is initialized correctly
STS token generation works

After server reboot:

Participant already exists
Participant creation is skipped
ParticipantContextConfiguration is empty
STS token generation fails with 500

Workaround

As a workaround, we are manually loading/populating the ParticipantContextConfiguration during startup.

However, we believe this is not the correct approach and that Identity Hub should restore the participant context configuration automatically after restart.

Has anyone experienced the same issue?
Is this expected behavior in 0.16.0 or could it be a regression?

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[paullatzelsperger]

first of all, version 0.16.0 is outdated, pls try again with the latest release.

next, please make sure you are using SQL persistence for both stores (participant and participant config). sounds like you are using in-mem persistence...

please understand we cannot debug, support or consider your custom extensions. whatever you develop is yours to maintain.

[alaguna-hiberuscom]

Hi, thanks for the answer.

We are planning to move to version 0.17.0 and we are currently using the BOM dependencies:

implementation(libs.edc.bom.issuerservice.oauth2)
implementation(libs.edc.bom.issuerservice.sql)
implementation(libs.edc.bom.identityhub.oauth2)
implementation(libs.edc.bom.identityhub.sql)

Is there any specific dependency required to persist and restore the participant conf using SQL?

We understand that our custom extensions are our responsibility. However, the 500 error is being thrown by the STS token endpoint, which is part of the EDC library itself.

Thanks.

[paullatzelsperger]

no, if you are using the BOM, the SQL participant context config store should already be on the classpath. However, feel free to double-check.

I have no idea how you are actually creating the participant context and the config, but if you are not using the API, you will need to make sure the participant context and the participant context config are created atomically, i.e. in a transaction.

To verify, run your extension, kill IdentityHub and check if everything is in the database.

We are not facing the same problem in any of our test environments (MVD or JAD), and I have no way of reproducing this supposed bug beyond that.

So unless you can provide a reproducible test (e.g. in a Gist), I'm afraid there is little we can do here.

As a general rule I would advise against seeding/prepopulating data using an extension. Instead, I would rely on external facilities such as bash scripts, Kubernetes jobs calling the APIs.

[edit]: but again, whatever you do henceforth, do it based on the latest official version at that time. we do not maintain old versions.

[alaguna-hiberuscom]

Hi,

Thanks for the info!
We was testing a little bit with version 0.17.0 and it is working correctly, so we are going to try to move to this version.

I think that The problem is that the table edc_participant_context_config does not exist in 0.16.0.

[paullatzelsperger]

I think that The problem is that the table edc_participant_context_config does not exist in 0.16.0.

I haven't double checked, but it is possible, that the SQL persistence got added later. Good that it works now 👍