RobotWebTools / rclnodejs / 35182297317

91%

push

github

preserve native type-description responses and prevent test leaks (#1608)

## Root Cause

The type-description service rebuilt the native ROS response through deserialize() and serialize() before sending it.

During this conversion, nested strings such as type_sources[0].raw_file_contents passed through StringWrapper.copyRefObject(). Its StringRefStruct(refObject.toObject()) copy decoded data using CString, which stops at the first NUL, but retained the original size and capacity.

The locally observed mismatch was:

| Property | Native response | Reconstructed response |
|---|---|---|
| String buffer length | 264 bytes | 263 bytes |
| Recorded size | 263 | 263 |
| Recorded capacity | 264 | 264 |

The native string had an earlier NUL at offset 262 and satisfied the terminator check at offset 263. CString copying shortened the allocation without updating its metadata.

The middleware subsequently checked data[size], reading beyond the reconstructed Buffer's bounds. Depending on adjacent memory contents, that check could pass or report "string not null-terminated", explaining the intermittent behavior.

Tracing confirmed that failing requests reached the service and were processed while service availability remained true. The response-send call returned without a JavaScript exception, but no usable reply reached the client, which eventually timed out. This was not simply a slow service startup.

A separate test-cleanup defect amplified the failure: the request interval was cleared only after receiving a response. After Mocha timed out and ROS shut down, the interval continued accessing a destroyed client, contaminating subsequent tests with invalid-client and duplicate-done errors.

## Fix

- Send the native type-description response buffer directly, removing the post-handler deserialize/serialize round trip that introduced inconsistent string metadata.
- Let the native ROS handler initialize the response, then free its native allocations in finally aft... (continued)

2271 of 2663 branches covered (85.28%)

Branch coverage included in aggregate %.

11 of 11 new or added lines in 1 file covered. (100.0%)

17853 of 19462 relevant lines covered (91.73%)

223.55 hits per line