Closed fabrizzio-dotCMS closed 1 week 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.
Tested in master
The conflicts appears as expected
https://github.com/user-attachments/assets/5f300b3a-4e32-42b0-b0d5-81bd1cedda31
But when i try to "Resolve conflicts" i see this:
https://github.com/user-attachments/assets/f71cb42f-aacd-4a69-ab09-ccb3f5f0e9c2
-First the conflicst cant be resolved -The second intent appears resolved -and when a new check integrity, the conflicts still appears
I think this ticket is only to see if the conflicts appears running in the same docker-compose, and maybe this is an error from my enviroment, but i report it anyway
Follow the detailed instructions in README (It is necessary to configure the IP correctly or you will have problems connecting both instances) https://github.com/dotCMS/core/tree/master/docker/docker-compose-examples/push-publish
Approved: Tested on trunk_7ad6b2a, Docker, macOS 14.5, FF v126.0.1
Parent Issue
No response
Problem Statement
These two files are meant to facilitate push-publishing testing
They should be used to start up two individual nodes. Typically one would end up running in port 8081 and the second in port 8082. Therefore they can be accessed from the browser typically by typing
http://localhost:8081/c
andhttp://localhost:8082/c
As the user consuming this pp-environment one is supposed to set up a remote endpoint so the sender node can talk to it by entering the IP address of the remote node. Typically a remote configuration should look like this:
Now Let's suppose you introduce a pp conflict between both nodes (sender and receiver) following the instructions outlined here https://github.com/dotCMS/core/issues/25229#issuecomment-1640982865
When you hit the
check integrity
button within this setup one would expect the report of the conflict. But in reality, nothing happens. No conflicts are shown here.And the reason is that the docker container doesn't resolve localhost As our localhost. It thinks that localhost is the same container itself. Regardless of the port number. It sees itself as localhost. Therefore these two instances can NOT see each other.
In reality, when you hit
check integrity
the dotCMS sender instance connects to itself. And the CSV file that gets downloaded contains the exact same image of the sender's database. Therefore no conflict arises when comparing. Because basically, it is comparing the instance against itself.I was able to corroborate this. Setting up a remote debugger against the sender node comparing that every time I added a new file or folder. The changes would make it into the file coming from the "remote" receiver.
On the other hand, if the same exercise is carried out against a true remote node with an "absolute" address that can be resolved by the container to an external IP. e.g. using demo. dotcms.com The remote endpoint this time shows conflicts as expected. Because the container internally was capable of resolving the address.
in short, localhost is ambiguous for the docker container. And we should try to use an absolute "real" IP address here for testing.
Potential solution: We could include both nodes (sender and receiver) in the same docker-compose and include in the networks an alias pointing to each one of the instances. And use that instance when configuring the PP Environments.
Steps to Reproduce
start up the two containers
These two files are meant to facilitate push-publishing testing
configure sender and make it point http://localhost:8081
now create a conflict following these instructions https://github.com/dotCMS/core/issues/25229#issuecomment-1640982865
Hit check integrity. You'll see no conflicts are found
Now repeat the same steps but this time using another endpoint pointing to demo.dotcms.com Now see how this time we have conflicts as we expected.
Acceptance Criteria
We should be able to use these files
To simulate PP and they should be able to see each other.
dotCMS Version
current master
Proposed Objective
Quality Assurance
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