ISSUE-724 # Increase JVM heap size for tests and use rawBody for large/binary responses to prevent OutOfMemoryError in Zerocode scenarios

[AfonsoPaiva]

Fixed Which Issue?

This contribution increases the JVM heap size for test execution also made it use "rawBody" instead of "body" for large or non-JSON responses. This prevents OutOfMemoryError when downloading or validating large files via API tests.
#724

PR Branch
https://github.com/AfonsoPaiva/zerocode/tree/download-large-file-fix

Motivation and Context

Checklist:

• 1. New Unit tests were added

  • 1.1 Covered in existing Unit tests

• 2. Integration tests were added

  • 2.1 Covered in existing Integration tests

• 3. Test names are meaningful

• 3.1 Feature manually tested and outcome is successful

• 4. PR doesn't break any of the earlier features for end users

  • 4.1 WARNING! This might break one or more earlier earlier features, hence left a comment tagging all reviewrs

• 5. PR doesn't break the HTML report features directly

  • 5.1 Yes! I've manually run it locally and seen the HTML reports are generated perfectly fine
  • 5.2 Yes! I've opened the generated HTML reports from the /target folder and they look fine

• 6. PR doesn't break any HTML report features indirectly

  • 6.1 I have not added or amended any dependencies in this PR
  • 6.2 I have double checked, the new dependency added or removed has not affected the report generation indirectly
  • 6.3 Yes! I've seen the Sample report screenshots here, and HTML report of the current PR looks simillar.

• 7. Branch build passed in CI

• 8. No 'package.*' in the imports

• 9. Relevant DOcumentation page added or updated with clear instructions and examples for the end user

  • 9.1 Not applicable. This was only a code refactor change, no functional or behaviourial changes were introduced

• 10. Http test added to http-testing-examples module(if applicable) ?

  • 10.1 Not applicable. The changes did not affect HTTP automation flow

• 11. Kafka test added to kafka-testing-examples module(if applicable) ?

  • 11.1 Not applicable. The changes did not affect Kafka automation flow

[Copilot]

Pull request overview

This PR attempts to fix OutOfMemoryError issues when downloading large files via API tests by increasing the JVM heap size in Maven Surefire and updating an archetype test to use rawBody instead of body. The changes stem from issue #724, where users experienced heap space errors when downloading files of ~200MB.

Changes:

• Increased JVM heap size for test execution by adding -Xmx2048m to Maven Surefire plugin configuration
• Modified archetype test file get_api_200.json to use rawBody instead of body for assertions, and reformatted the JSON

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
pom.xml	Added JVM heap size configuration (-Xmx2048m) to Maven Surefire plugin in pluginManagement
zerocode-maven-archetype/.../get_api_200.json	Changed assertion from "body" with JSON object to "rawBody" with escaped JSON string, and reformatted file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The change from "body" to "rawBody" in this archetype template is inappropriate. The GitHub API /users/octocat endpoint returns valid JSON (application/json), not raw text or binary data. The "rawBody" field should only be used for non-JSON responses like XML, plain text, or binary content.

According to the PR description and linked issue #724, rawBody is intended for "large or non-JSON responses." However, this is a standard JSON response from GitHub's API. All other GitHub API test examples in the codebase (e.g., http-testing-examples/src/test/resources/loadtesting/github_get_api_test_case.json) use "body" with JSON object assertions, not rawBody with escaped JSON strings.

The original code with "body": {"login": "octocat"} is the correct pattern for JSON responses and should be restored.

Suggested change

	"rawBody": "{\"login\":\"octocat\"}"
	"body": {
	"login": "octocat"
	}

[Copilot]

The hardcoded argLine configuration in pluginManagement will conflict with the JDK 17+ profile at lines 462-485. The JDK 17+ profile sets its own argLine with --add-opens flags required for Java 17+. When both are present, only one argLine will take effect (typically the profile's configuration overrides pluginManagement).

This means that either:

1. JDK 17+ users will lose the -Xmx2048m setting, or
2. Users on older JDKs will lose the --add-opens flags if the profile logic fails

The recommended solution is to use the @{argLine} placeholder pattern to allow both configurations to be combined. In pluginManagement, use <argLine>-Xmx2048m</argLine>, and in the JDK 17+ profile, use <argLine>@{argLine} --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED</argLine>. Alternatively, add the memory configuration to the JDK 17+ profile as well.

Suggested change

	<configuration>
	<argLine>-Xmx2048m</argLine>
	</configuration>

[authorjapps]

@AfonsoPaiva , could you please take a look at the review comments and resolve them please?