Given a large payload is returned

When Debug Output Reaches a maximum allowed characters

Then a “…” button is shown that allows, when clicked, to view the full payload.

Currently, this just errors when pressed.

I already have my Azure based HPC PoC and I am using warewolf provisioning tool. Come across an issue trying to set up PXE boot to provision nodes. Found out that azure does not support PXE boot on its virtual machines. I have read of work-arounds and one of them was to set up nested hyper-v VMs. Has anybody successfully done this ?

I'm currently working on a service that requires setting a custom Accept header with the following value:

Accept: application/vnd.sasgtwy.v1+json

However, when I attempt to configure this in the HTTP Web Request tool within Warewolf, I receive the following message:

"The Accept header must be modified using the appropriate method or property parameter name: name"

It seems Warewolf expects the header to be set using a specific method or parameter, but it’s unclear how to apply this properly. I've tried adding it in the Headers section, but without success.

When Creating a Unit Test for a workflow that has a sequence tool with a couple of tools inside the sequence the Studio freezes and eventually crashes.

This happens on v2.8.13.10

🔹 1. Web Request Tool — Parse Error on Binary Response

• When attempting to download a Genesys pre-signed audio file (MP3) via the Web Request tool, Warewolf throws a:

  nginxCopyEditparse error: { AudioFile }
  

• The tool does not provide any options to specify how the response should be handled (e.g., as text, binary, or base64). It attempts to parse the response automatically.

• 🧠 Root Cause: The tool likely assumes the response is text or structured data, and fails when encountering raw binary bytes from the audio stream.

🔹 2. GET Web Method Tool — Output Mapping Fails on File Response

• When using the GET Web Method tool to call the same audio file URL and clicking "Generate Outputs", the following error is shown:

  pgsqlCopyEditSpecified argument was out of the range of valid values.
  Parameter name: count
  

• Output mapping options (like assigning to object/recordset) are greyed out because the tool fails to test or build outputs from the binary response.

• 🧠 Root Cause: Since the endpoint returns raw binary (audio/mpeg), the tool cannot generate a data structure for mapping and gracefully disables output binding.

  Response when trying to test get api

While trying to connect to the third party's SFTP server through Warewolf, I encounter the following error. I am able to connect using FileZilla without any issues. I tried connecting to one of our internal SFTP servers through Warewolf to check if it was working, and it connected successfully.

It seems like the issue might be that the password is not supported by the Warewolf tool. Third party's SFTP password is 20 characters long and contains a comma and a backslash (special characters). While our internal SFTP password is 7 characters long and contains plus sign.

The current Docker image for the Warewolf application is based on Windows Server 2019 (ltsc2019) with the following characteristics:

• OS Version: 10.0.17763.6659

• Architecture: amd64

• Image Size (Uncompressed): ~7.06 GB

• Includes: Warewolf server, PowerShell-based entry point script

• Base Image: mcr.microsoft.com/windows/servercore:ltsc2019

Due to the use of the Windows Server 2019 servercore base image, the resulting image is relatively large. However, Windows Server 2022 introduces significant improvements that justify a migration:

 Benefits of Migrating to Windows Server 2022:

• Reduced base image size (~700 MB smaller)

• Faster container startup times

• Improved runtime and networking performance

Estimated reduction: ~1 GB or ~15–20% smaller overall image size.

Hi Warewolf Team,

We've encountered a regression issue with the Post tool in version 2.8.6.16. Specifically, the tool fails to map data correctly when posting to RabbitMQ. After some investigation, we confirmed that downgrading to version 2.8.1.3 resolves the issue — the mappings function as expected in that version.

This tool is central to several of our microservices workflows, particularly those under the Tech Titans initiative, so the impact is significant.

Steps to reproduce:

1. Use the Post tool in v2.8.6.16 to send data to RabbitMQ.
2. Attempt to map the data.
3. Observe that mapping fails or data is not passed as expected.
4. Roll back to v2.8.1.3 and observe that the same mapping succeeds.

Additional notes:

• There are a number of prior posts in the community related to the Post tool not working as expected.
• This issue appears to have resurfaced or persisted in the latest versions.
• We'd appreciate clarity on whether a fix is planned or if a stable workaround exists.

The following snips indicates how it maps correctly in v2.8.1.3:

The following snips indicates how it incorrectly maps in v2.8.6.16:

Additional steps taken:

I also took the workflow that works in v2.8.1.3 and then ran it in v2.8.6.16 and got the following result: (Please note it works in v2.8.1.3)

I do have a sample workflow that I can provide, but not on the community, as it will expose the authorization token used by the client. Please contact me for this, and I will provide it to you.

Thanks in advance,

Wynand

Hello team,

We’d like your support with regards to a suspected RabbitMQ challenge that we are currently experiencing on an integration project within the business.

To provide context at a high level, we are looking to communicate with a 3^rd Party Service Provider via RabbitMQ. We will thus publish a payload of an event in the business to their RabbitMQ instance.

Herewith are some challenges we are currently facing:

1. When trying to add a new RabbitMQ source, we are unable to save the source due to the error in the screenshot below:

2. We then changed the host of the RabbitMQ source, now the URL is specified without https:// and we received a different error in the screenshot below: (Possible DNS issue? - Please note, also unable to save the source)

3. We were able to get around the above challenge by editing the RabbitMQ source file outside of Warewolf in NotePad++.

4. When we continued testing, we saw that we are running into a different challenge at the point of publishing the payload to their RabbitMQ instance, error reflecting in the screenshot below:

5. We also further observed that the service providers is using quorum as a queue type, compared to the normal Classical queue type that we normally use, as represented below:

6. Another difference we observed was that the 3^rd Party was using a / in the name of their Virtual Host.

7.We were successfully able to test via Postman, as per the screenshot below:

Herewith the details used for the RabbitMQ source: (Please obtain password from Elmans)

https://za-rabbitmq.20.87.64.78.sslip.io
5672
UnlimitedStaging
Password – (obtain from Elmans)
/UnlimitedStaging

Looking forward to your feedback.

Regards,

Wynand