Parts not updated after resync via IRS

[ds-mwesener]

Description

When synchronizing parts, unsuccessful sync attempts lead to the creation of tombstones. A subsequent sync attempt works but does not convert the existing tombstone back into a normal part.

Current behaviour

• Unsuccessful sync of parts results in tombstones.
• Successful re-sync does not transform the tombstone into a regular part.

Expected behavior

• Unsuccessful sync should create tombstones, (As-Is)
• In case of a subsequent successful sync, the tombstone is removed, and the asset is imported as usual.
• No sql errors in log for syncing assets with the irs.

Out of scope

• Tombstone history for not successful syncs

Steps to reproduce the Bug

1. AdminView -> Create a policy which is different to the default policy
2. AdminView -> Import Data into Trace-X (Parts) -> choose policy which has been created in step 1)
3. While the application has not restarted try to sync assets
4. Trace-X will use the policy which was setup on startup which is not matching with the created one and therefore sync will fail.
   -> Parts are not synced correctly
5. AdminView -> Delete All policies
6. Restart trace-x -> now the policy should match
7. Reload registry
8. Parts should be updated and have data

Or easier:

1. Login to db
2. Change a field of a successful synced part
3. Regtriy reload
4. See attribute has not been updated

[ds-mwesener]

Please find some logs about an initial registryReload, attached on the ticket.

[ds-mwesener]

logs_after_sync.txt

[ds-lcapellino]

Tested on dev environment together with @ds-mwesener. All assets got updated as expected, tombstones got overriden after successful sync. No SQL exceptions visible in logs.

[ds-crehm]

Tested on E2E:
After changing to a wrong policy, the part is replaced by a tombstone. When changing back to the correct policy and syncing again, the tombstone is again replaced with the correct data.

Ready for review.

[ds-crehm]

During testing of #884 we noticed some SQL errors in the logs, which must be fixed. Will move this ticket back to WIP.

[ds-lcapellino]

After merging PR
No exceptions regarding duplicate key errors are thrown, However, error logs like:

2024-07-08T11:45:22.569Z ERROR 1 --- [nio-8080-exec-6] o.h.engine.jdbc.spi.SqlExceptionHelper   : ERROR: duplicate key value violates unique constraint "asset_pkey" Detail: Key (id)=(urn:uuid:0733946c-59c6-41ae-9570-cb43a6e43842) already exists.

might still be visible. The error is followed by a info log:

Asset with id urn:uuid:0733946c-59c6-41ae-9570-cb43a6e43842 already exists in the database. The record will be updated instead.

This indicates, that the error was handled properly.

To test the fix, simply delete all assets with:

truncate assets_as_built, assets_as_planned cascade;

and trigger the asset synchronization via the frontend.

No stack traces regarding SQL exceptions should be visible.

[ds-crehm]

Tested on dev:
Duplicate key error happens sometimes with the info log as mentioned by @ds-lcapellino.
Couldn't find any other SQL exceptions.

Ready for review.

[ds-lcapellino]

Bug found during fixing in IRS: #755

[mkanal]

LGFM. Shown dugin review. PO acceptance in behalf of @jzbmw.