We have a valid uSync complete company license that we use for our clients. On a v8 project, we use uSync complete on their servers. They have a DEV, TEST, ACC and PROD server. The uSync configuration is in the deploy pipeline of GIT and hasn't changed since 2022. It has always worked since then. Since beginning of december 2024 the client isn't able to publish content on TEST (pushing content). I checked it myself: - I can publish from ACC to PROD - I can publish from DEV to TEST - But I am not able to publish from TEST to either DEV or ACC While going over the uSync publisher settings in the backoffice on TEST, I can check the access to the configured servers. DEV and ACC are listed as available. So there doesn't seems to be an access issue. Publishing existing content to another server doesn't work. However, we found a work around. There is still a error message, but new content does get published. Deleting content on another server makes it "new". The Umbraco logs don't provide us much to go on. Remote Error: InternalServerError (/umbraco/uSyncReceive/uSyncReceiveApi/ImportPackFolder) Content: [] at uSync.Publisher.Publishers.SyncPublisherBase.d__12.MoveNext() The "servers" are Azure app services and don't provide more information.

Hi Sven, there should be a bit more logging on the server you are pushing too, the error you get back from a server is often quite basic (such as internal server error) because of locked down config - but the server it self should give a bit more info. What we have seen before is that ImportPackFolder is often the first "POST" request that also uploads a file to the other server in the process, and things work fine until that point as GET requests. we have seen people have issues because of firewall or proxy issues, either block the post, or don't like that the data is being passed in a zip file format (its uploaded with a conten type of application/zip). this can cause the firewalls to throw, and sometimes that comes back as the 500 you are seeing. but i would also check the server logs incase its something else

Hi Kevin. Thanks for the quick response. I will have to pass the information on to someone else. What I heard from him, is that there aren't actual server logs, beceause it is not an actual server (but an app service). I am glad we found a work around, but is that normal? That it DOES work with new content?

hi, yeah umbraco still has logs, though so , it should show something in them (on the server, go to settings, log viewer).

In the Umbraco backoffice of the accepting server (the one where we publish TO), there are no logs regarding uSync at all. I checked that after your response. In Azure, app logs are disabled. I have access to the Azure app service, but it is not my companies responsiblity to change things.

thats odd, because uSync certainly logs stuff (especially errors). we have some docs on logging setup for v8 to help debugging, https://docs.jumoo.co.uk/usync/8.x/uSync/guides/debugging its possible that the default log levels have been turned down on the production servers (certainly a thing people do). and that's why there is nothing to see.

I changed the log level to verbose now. A lot more is logged, that is true. But in the mass of information, I still can't detect a root cause. There are no errors in the receiving server. I can see a success: incoming server verified. And a content based token raw (uSync.Publisher.Security.HMACAuthenticationAttribute') That is about all that is tied to the publish.

yeah it logs a lot like that 🙁 - search for the 'ImportPackFolder' line in the servers logs and see if you see anything, its still possible it isn't getting to the server

I checked. Even my search for ImportPackFolder is now logged 🙂 The last information about the publish (on the receiving server), doesn't provide more information then this: Timestamp 2025-01-06T13:46:43.68529+00:00 @MessageTemplate Content based token Raw: {raw} raw 61be8329-df0a-43ea-b216-6153093435bcPOSThttps%3a%2f%2fas-coro-weu-a-umbraco-cd.azurewebsites.net%2fumbraco%2fusyncreceive%2fusyncreceiveapi%2fimportpackfolder1736171203d85134a4-95dd-49fa-8e53-eeda96ff9b244mWvLGF/IsMoDyixSqvZAw== SourceContext uSync.Publisher.Security.HMACAuthenticationAttribute ProcessId 9452 ProcessName w3wp ThreadId 7 AppDomainId 2 AppDomainAppId LMW3SVC84588296ROOT MachineName Log4NetLevel ALL HttpRequestNumber HttpRequestId 896ae42b-2e91-4ce6-a8d7-51d9bc825a7a

Hi, i will need to go look at the v8 code to see if there is anything else it might report at this point 🤔

Thanks!

Hi, Yeah with these two in the log file (although the one you already had should show the "[ImportPackFolder]" line you should see logging on the server you are pushing to with the v8 version. this looks a bit like this on the target (when it works) -* see image* also the actual code for this means you really should be showing an error if something is going wrong on the server as the whole lot is in a try catch that logs.

cs
private SyncPublishResponse DoPublisherStep(PublisherActionRequest options, Func<SyncPublishRequest, SyncPublishResponse> action)
 {
     EnsureEnabled();

     try
     {
         var hub = new HubClientService(options.ClientId);
         var callbacks = hub?.Callbacks();

         var request = options.ToPublishRequest(callbacks);

         var response = action(request);

         if (response != null)
             return response;

         throw new EntryPointNotFoundException(nameof(action));
     }
     catch (Exception ex)
     {
         logger.Error<uSyncReceiveApiController>(ex, $"Fail on Publisher Step: {options.ActionAlias} {options.StepIndex} {options.PageNumber}");
         throw;
     }
 }

https://cdn.discordapp.com/attachments/1325784770973798443/1328758694619385950/image.png?ex=6787de77&is=67868cf7&hm=54cec48ed0d977c1c510766ffce15a26bc824de422904b9e912cdd4f2125429a&

Thanks. I will try it out and update here when I do.