DAL workflow works when run on it's own, but not when it is a sub-workflow?

The test still works fine though...

Screenshot taken from Warewolf 2.7.4.7

I'm not sure I understand. In my experience the test execution goes by the order the tools are executed in the workflow. For me, it always finds the correct assert/mock no matter what order the asserts/mocks are in. Can you give some example workflows and tests to demonstrate this behavior more clearly?

I have reposted this private ticket so the rest of the community can learn from it.

Json data is handled in Warewolf as object variables, see: https://warewolf.io/knowledge-base/articles/the-warewolf-esb-syntax/#:~:text=up%20to%20%E2%80%9Cn%E2%80%9D-,Objects,-The%20notation%20for

Object variables can be set as inputs using the variable list, see: https://warewolf.io/knowledge-base/articles/the-variable-list/ 

Once they are inside your workflow they can be manipulated using the Assign Object, and Select and Apply tools, see: https://warewolf.io/knowledge-base/articles/tool-connectors/#:~:text=%C2%A0Data-,Assign%20Object,-Use%20the%20Assign

New json objects can be created using the Create Json tool, see: https://warewolf.io/knowledge-base/articles/tool-connectors/#:~:text=the%20Staff()%20recordset.-,Create%20Json,-Use%20the%20Create

Then you can use the Web Service tool to make a HTTP POST request with the json object in the body, see: https://warewolf.io/knowledge-base/articles/the-web-service-tool/

You can use
http://[[REMOTE SERVER ADDRESS]]:3142/secure/getserverversion.json
or
http://[[REMOTE SERVER ADDRESS]]:3142/secure/ping.json
To test your connection to a remote server.

EDIT: Where [[REMOTE SERVER ADDRESS]] is the hostname or IP address of the remote server.

That error is expected if there is no local server running. Test connection tests the connection between two servers, localhost and the remote server.

I've investigated the logging for testing a new server source and execute from browser. I have found the currently logged data to be sufficient. I can see no evidence in either of those logs of testing a server source or executing from the browser. Your original question was about the studio freezing, which I believe has been answered. So I'm going to close this ticket. Please open a new topic for discussing the "Exception: Unable to contact Server" error in the new server source dialog, if the problem persists. One that includes both server log files and the studio log file showing the full payload for the "TestConnectionService" in the studio log and "execute web request" in the remote server's log.

Hmmm, that's not right. If you can execute from the browser with the Public uri that means you have permission to connect as Public user. I just tried with another machine on my local network and I cannot replicate that behavior. This is nit-picking, but I noticed you cropped out the port in the New Server Source dialog. If that port is not "3142" it would cause that "Unable to contact Server" error. Otherwise I can add more logging around testing a new server source connection. Just need your logs again for server and studio from:
%programdata%\warewolf\Server Log\wareWolf-Server.log
%localappdata%\warewolf\Studio Logs\Warewolf Studio.log

Here are zipped release builds of the server and studio to compare the performance of your compiled builds against:

https://warewolfreleases.s3.eu-west-1.amazonaws.com/Server-2.6.4.10.zip
https://warewolfreleases.s3.eu-west-1.amazonaws.com/Studio-2.6.4.10.zip
This will rule out any compile time causes for the studio freezing.

Your logs appear to rule out a server side cause. The studio logs are at:
"%localappdata%\Warewolf\Studio Logs\Warewolf Studio.log"

Here is my studio log after I opened the studio, opened an example workflow and executed it:
Warewolf Studio.log

If your log is not conclusive we will have to debug the studio. I am happy to remote into the machine to debug the studio if it is on the cloud. Otherwise I can help you find the right thread to debug yourself. There are a number of possible threads that could cause the UI thread to freeze.