Skip to content

Conversation

@erossignon
Copy link
Contributor

…1400

@codecov
Copy link

codecov bot commented Oct 15, 2025

Codecov Report

❌ Patch coverage is 63.76812% with 50 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.41%. Comparing base (3325e12) to head (92fcbd8).
⚠️ Report is 32 commits behind head on master.

Files with missing lines Patch % Lines
...ackages/binding-opcua/src/opcua-protocol-client.ts 29.57% 50 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1449      +/-   ##
==========================================
- Coverage   77.58%   77.41%   -0.17%     
==========================================
  Files          79       84       +5     
  Lines       15331    15989     +658     
  Branches     1445     1519      +74     
==========================================
+ Hits        11894    12378     +484     
- Misses       3414     3585     +171     
- Partials       23       26       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@JKRhb JKRhb linked an issue Oct 16, 2025 that may be closed by this pull request
const variantInJson = opcuaJsonEncodeVariant(dataValue.value, false);
const content = contentSerDes.valueToContent(variantInJson, schemaDataValue, contentType);
return content;
} else if (contentType === "application/octet-stream") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the general problem with the current code is that it right away decodes the data on the wire. It should first get the data raw and afterwards the ContentSerdes decodes the data.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take a look at CoAP for example where the readResource call returns the raw data

public async readResource(form: CoapForm): Promise<Content> {
const req = await this.generateRequest(form, "GET");
debug(`CoapClient sending ${req.statusCode} to ${form.href}`);
return new Promise<Content>((resolve, reject) => {
req.on("response", (res: ObserveReadStream) => {
debug(`CoapClient received ${res.code} from ${form.href}`);
debug(`CoapClient received Content-Format: ${res.headers["Content-Format"]}`);
// FIXME does not work with blockwise because of node-coap
const contentType = (res.headers["Content-Format"] as string) ?? form.contentType;
resolve(new Content(contentType, Readable.from(res.payload)));
});
req.on("error", (err: Error) => reject(err));
req.end();
});
}

Afterwards the configured ContentSerdes deals with the actual content and whether the "byte stream" is JSON, CBOR or anything else..

The same should happen with OPC UA....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the current code is that it right away decodes the data
In fact this code is where the encoding takes palce;( not decoding)

@danielpeintner
Copy link
Member

I tried to test the PR with a simple example and I think it does not work as expected. Maybe I am just not understanding it properly.

As mentioned in #1400 OPC-UA seems to work fine until I add contentType.

Note: FYI, not adding any contentType at all would mean JSON which is not the case for OPC UA I believe.

If I add
"contentType": "application/octet-stream"
in a form the codec tries to do work... which has been done already.

Also, it seems that the according code hasn't changed in that regard.

Try to add "contentType": "application/octet-stream" in a simple TD and you will get something like.

throw new Error(`application/octet-stream only supports primitive types (boolean, integer, number, string) - got ${form.type}`);
                          ^

Error: application/octet-stream only supports primitive types (boolean, integer, number, string) - got undefined

@erossignon
Copy link
Contributor Author

I tried to test the PR with a simple example and I think it does not work as expected. Maybe I am just not understanding it properly.

As mentioned in #1400 OPC-UA seems to work fine until I add contentType.

Note: FYI, not adding any contentType at all would mean JSON which is not the case for OPC UA I believe.

If I add "contentType": "application/octet-stream" in a form the codec tries to do work... which has been done already.

Also, it seems that the according code hasn't changed in that regard.

Try to add "contentType": "application/octet-stream" in a simple TD and you will get something like.

throw new Error(`application/octet-stream only supports primitive types (boolean, integer, number, string) - got ${form.type}`);
                          ^

Error: application/octet-stream only supports primitive types (boolean, integer, number, string) - got undefined

Could you provide an example of things that reproduce what you're doing. That would be easier to grasp . My understanding should be clearly available in the new unit test added. May be I missed your specific case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ContentType seems to confuse OPC UA

2 participants