Uploaded image for project: 'Magnolia Synchronization Module'
  1. Magnolia Synchronization Module
  2. MGNLSYNC-57

Synchronization Manager does not handle sync requests for the same workspace

    XMLWordPrintable

Details

    • Bug
    • Resolution: Inactive
    • Neutral
    • None
    • None
    • None
    • None

    Description

      I'm using the synchronization manager to sync content to new publics. The first synchronization request managed by the manager will work fine, but a second request for the same workspace (to sync another public) will get stuck in a WAITING state. 

      I can see this even when making use of the synchronization-rest module. 

      Steps to reproduce

      1. Start up an author with some content ready to sync. (I think the website workspace will work, but all my workspaces are for content apps).
      2. Start up a public, and register it as a receiver on the author.
      3. Using the synchronization-rest module, hit the synchronization/trigger endpoint:
        https://docs.magnolia-cms.com/product-docs/Modules/List-of-modules/Synchronization-module/Synchronization-REST-module.html#_trigger_synchronization
        I.E: 
      curl -u superuser:xxxxx https://cms-author-dev.deveng.systems/.rest/synchronization/v1/trigger --data '{"url" : "http://cms-public-dev-1.deveng.systems:8080", "workspace": "argos-browse-pages", "fromPath" : "/", "recursive": "true"}' --header "Content-Type: application/json"
      1. Note that, after some time, the content from the workspace you specified will be synced to the public. You can also track the progress with the status endpoint, and this will work fine. (https://docs.magnolia-cms.com/product-docs/Modules/List-of-modules/Synchronization-module/Synchronization-REST-module.html#_get_status)
        E.G: 
      { "executionStart": 1619434630223, "executionEnd": 1619434692567, "cancelled": null, "state": "DONE", "created": 1619434630191, "identifier": "synchronization-20210426-105710191", "workspace": "argos-browse-pages", "path": null, "recursive": true, "fromDate": null, "template": null, "url": "[http://cms-public-dev-1.eu-west-1.dev.deveng.systems:8080|http://cms-public-dev-1.eu-west-1.dev.deveng.systems:8080/] ", "fromPath": "/", "toPath": null }
      1. Now start up a second public, and register it as a receiver on the author.
      2. Using the synchronization-rest module, hit the synchronization/trigger endpoint again, for the new url, but the same workspace:
      curl -u superuser:xxxxx https://cms-author-dev.deveng.systems/.rest/synchronization/v1/trigger --data '{"url" : "http://cms-public-dev-2.deveng.systems:8080", "workspace": "argos-browse-pages", "fromPath" : "/", "recursive": "true"}' --header "Content-Type: application/json"
      1. Make a note of the synchronization request id that the above curl returns.
      2. Note that, after some time, you will see the author begin to sync content across to the second public. However, If you use the status endpoint, you'll see that the request is stuck in a WAITING state, even after all the content is synchronized. E.G:

       

      { "executionStart": null, "executionEnd": null, "cancelled": null, "state": "WAITING", "created": 1619435706391, "identifier": "synchronization-20210426-111506391", "workspace": "argos-browse-pages", "path": null, "recursive": true, "fromDate": null, "template": null, "url": "[http://cms-public-dev-2.eu-west-1.dev.deveng.systems:8080|http://cms-public-dev-2.eu-west-1.dev.deveng.systems:8080/] ", "fromPath": "/", "toPath": null }
      

      Expected results

      The second request should correctly track the progress for synchronising that content to the new public. 

      Actual results

      The second synchronisation request will always state that it is WAITING. 

      Workaround

      Restarting author seems to fix this for one request (the second request will then get stuck WAITING again) 

      Development notes

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              Unassigned Unassigned
              bmurdoch Brandon Murdoch
              Nucleus
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Checklists

                  Bug DoR
                  Task DoD