dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
846 stars 465 forks source link

Integrity Checker Fails to solve Conflict on the Remote Host #25302

Open fabrizzio-dotCMS opened 1 year ago

fabrizzio-dotCMS commented 1 year ago

Parent Issue

Discovered while working on https://github.com/dotCMS/core/issues/25229

Problem Statement

If we're trying to solve a conflict on the remote host and the identifier we're trying to use is already taken by another asset. The issue resolution fails.

Steps to Reproduce

Since we now have Deterministic identifiers creating a conflict between a sender and receiver becomes a bit tricky but not impossible. In order to reproduce Set up a push-publish environment (sender and receiver) both using full-starter.

  1. On the receiver node create a folder let's say we name it "foo"
  2. On that folder upload a file
  3. Repeat these same 2 steps but this time on the sender node. Verify the identifiers of the file asset are the same for both sender and receiver.
  4. Now in order to trick the deterministic identifiers on the receiver node cut the file asset named "bar" and paste it somewhere else outside the folder "foo".
  5. Now reupload the same binary under the "foo" folder on the receiver node. Verify the identifiers are different this time.
  6. Now set up the PP Environments on the sender. Once ready hit "Check Integrity" an Error must be reported here.
  7. Now that you have seen that there's an error on the Files Tab. Hit the Fix Button On the Remote Node.
  8. An Internal Error message is returned here. Not much is in the logs.

The reason for this error is that Our Integrity Checker does not know how to deal with existing identifiers on the receiving end. if upon a closer look the error more or less looks like this:

com.dotmarketing.exception.DotDataException: ERROR: duplicate key value violates unique constraint "contentlet_version_info_pkey"
  Detail: Key (identifier, lang, variant_id)=(d915bbd9697fd94a20159b4157a4e552, 1, DEFAULT) already exists.{
  "SQL": ["INSERT INTO contentlet_version_info(identifier, lang, working_inode, live_inode, deleted, locked_by, locked_on, version_ts) SELECT ?, ?, ?, ?, deleted, locked_by, locked_on, version_ts FROM contentlet_version_info WHERE identifier = ? AND working_inode = ? AND lang = ?"],
  "maxRows": [-1],
  "offest": [0],
  "params": [
    "d915bbd9697fd94a20159b4157a4e552",
    1,
    "368609d3-6800-489a-9e61-232f5f93c67a",
    "368609d3-6800-489a-9e61-232f5f93c67a",
    "32b340e5-3a16-4aa6-9aa2-4c092aba9b76",
    "ed1d5899-7781-4535-9e82-7a625393a6c3",
    1
  ]
}
    at com.dotmarketing.common.db.DotConnect.loadResult(DotConnect.java:276) ~[dotcms_master_d71ee8c.jar:?]
    at com.dotcms.integritycheckers.ContentFileAssetIntegrityChecker.fixContentletConflicts(ContentFileAssetIntegrityChecker.java:321) ~[dotcms_master_d71ee8c.jar:?]
    at com.dotcms

Remember that the identifier that we're getting from the sender already exists on the receiving end. receiving

https://github.com/dotCMS/core/assets/37148755/fb0f271a-3526-41c7-b76b-5113f1343778

Acceptance Criteria

We should be able to solve conflicts in both sender and receiver at all times But the solution for this isn't very straightforward straightforward if we instruct the IC to assign a new identifier to the current piece of content that holds the offending identifier we could end up generating a new conflict.

The way around to make this work is deleting the original file holding the identifier we want to replace or solve the problem for the sender.

dotCMS Version

current master

Proposed Objective

Customer Success

Proposed Priority

Priority 3 - Average

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.