objectJSON in HTTP integration

I’m trying to understand the fine details surrounding the use of “codecs” for payload decoding, and the resulting data. Hope that someone can clarify a bit.

I configured a custom JavaScript codec. It returns an object with key/value pairs.

Now, when I look in the web interface at the “Device Data” tab for a node, unfolding the details for an uplink packet appears to show a proper object for “objectJSON”. However, when I look at the data that is posted via the HTTP Integration (with the “JSON” marshaler selected), the “objectJSON” key is present but doesn’t contain a proper JSON object, it contains a stringified version.

I found two references in the forum about this, but I don’t understand yet why it behaves like this. It’s quite a pain to parse the whole message and retrieve specific fields from the decoded payload when halfway through the JSON path one has to throw in some specific type cast, while all the rest already is properly structured JSON.

I haven’t tested the “legacy” JSON marshaler yet (is this the json_v3 that was also referred to?), because it will be deprecated. Is it possible to get a future proof way to get a proper JSON object through the HTTP integration?

Looks like the formatting for the web frontend was fixed in commit 75fcf7fda4af23945f33429987df129e33b2a135 [1] that was included in v3.10. I’m new to the project and have never written Go myself, so trying to understand: is it a deliberate choice not to implement a similar fix in the HTTP integration, is it very difficult to fix there or is it not considered as an issue?

[1] https://github.com/brocaar/chirpstack-application-server/commit/75fcf7fda4af23945f33429987df129e33b2a135

Now also tried the payload marshaler “JSON (legacy, will be deprecated)”; this one does appear to send full JSON objects (with the payload codec result in a key named “object”. So this looks like a short term fix for me, but a risk for the future as it’s marked for deprecation.

The reason for this is that the message-format is pre-defined by a Protobuf definition. The only thing that should be needed is to parse the string again as JSON.