Error: Need to register statements twice

[RikkeVestesen]

There appears to be an error in ITB when assigning new statements to systems. When I select “create statements,” it does not work the first time, so I have to do it twice. Can you help with this?

Thank you in advance for your help.

Kind regards
Rikke

[costas80]

Hi @RikkeVestesen. This was also reported a few days ago by another user. It should be resolved in the upcoming 1.29.0 release to be published this week.

Let's keep this issue open until then - I'll ping you when the new release is published to check again.

[costas80]

By the way, if you would like to get the fix immediately you could switch your development environment to our nightly build where the fix is already available. Once the 1.29.0 release is published you can switch back if you prefer.

If you don't mind trying this out as I suggested it would be quite helpful in ensuring this is resolved. We find this issue is difficult to reproduce (at least on our end), so if you consistently see it, it would be great to ensure via the nightly build that it is fixed.

[RikkeVestesen]

Hi @costas80

Thank you for your response.
We are using nightly builds already. We are using version 1.29.0-snapshot (2026-03-16). Should the issue be fixed in this version, or should we update to test it?

[costas80]

The fix for this was published on 19/03 so indeed it's not included in your instance. Could you please pull the latest nightly build and check if the issue is resolved?

If the issue is still present then it would help a lot of you pasted the latest log output from the itb-ui container. We've added log statements to the points where a conformance statement creation could get skipped that should help pinpoint the cause.

[costas80]

Hi @RikkeVestesen. For info, the discussed fix is now included in the stable 1.29.0 release that was just published.

[olw-medcom]

Hey @costas80 it seems the issue is still present. I'm trying to find itb-ui logs, what can I search for to find the log output you've done? My logs are filled with this:
09/04/2026 08:58:33 WARN com.zaxxer.hikari.pool.PoolBase - default.db - Failed to validate connection com.mysql.cj.jdbc.ConnectionImpl@2f20457f (No operations allowed after connection closed.). Possibly consider using a shorter maxLifetime value.

Do you have a clue on how to remove these logs that I could communicate to my infrastructure provider?

[costas80]

Hi @olw-medcom. There are new log statements that indicate when statement creation gets skipped such as this:

Conformance statement already exists for system[X] specification[Y] and actor[Z]

The logic followed in the implementation is not complicated. The relevant IDs needed to create the statements are collected and then they are used to see if a given statement exists before creating it. There must be something causing this second check to prevent the creation, which is what the logging captures. If you replicate the issue and manage to extract such logs it would help debug this.

This issue is a pain to investigate. It reproduces only rarely (or not at all) indicating some sort of race condition or incomplete state. In fact the warning you noted from the logs could be an interesting point to check as there could be an external factor (stale connection?) that kicks in here.

[costas80]

By the way @olw-medcom, I'm curious whether you see this coming up regularly or if it's also difficult to reproduce for you. As you're running the nightly build (if still the case) we could try putting in place an update that targets this and try to reproduce before making a full patch release (in our dev/test environments this has been impossible to reproduce so far).

I'll have an updated build for this in a few days (I'm away from work this week) and we can follow up then. In the meantime any additional info and logs you can collect would be very helpful.

[olw-medcom]

Alright! I have some log configuration to do as my log is filled to the brim, and I can't go back very far back in time because of it. My provider is able to look into the warning logs by next week, so I will have to wait until then. We are still running the nightly build, so yes once the warning logs have been fixed, I will gladly try to help to reproduce this bug and help resolve it 😊 I will let you know, when I'm ready for it

[costas80]

By the way it's surprising you are getting so much logging for these stale connection warnings. As I mentioned before, this could be linked to the root cause of this issue and the reason why this has been tough to reproduce (we never get those is freshly spun up test instances).

As part of this issue we'll also check to see what is causing these log warnings and address them correctly as part of the itb-ui's configuration (rather than just silencing them).

[olw-medcom]

I am also surprised, I don't get it on my local machine, so I'm not sure what's up, but it could definitely be related. I'm not sure what my infrastructure provider is to do about it though, but hopefully they know something.