NdjsonSerializer adds a leading comma to lines 2+ of each batch, so parsers drop them

[Pablo1]

Version:

• Release v3.0.0 (also on master at afa9797)

OS and platform:

• Ubuntu 26.04
• Technitium 15.4

Configuration:

{
  "sinks": {
    "maxQueueSize": 50000,
    "enableEdnsLogging": true,
    "console": {
      "enabled": false
    },
    "http": {
      "enabled": true,
      "endpoint": "https://victorialogs.example.com:9429/insert/jsonline",
      "headers": {
        "VL-Time-Field": "timestamp",
        "VL-Msg-Field": "question.questionName",
        "VL-Extra-Fields": "app_name=TechnitiumDNSServer,host.name=host.example.com,severity_text=INFO",
        "VL-Stream-Fields": "app_name,host.name"
      },
      "ndjson": true
    }
  },
  "pipeline": {
    "normalize": {
      "enabled": true
    },
    "tagging": {
      "enabled": false,
      "tags": [
      ]
    }
  }
}  

Error Message:

2026-09-17T08:15:45.207Z warn VictoriaLogs/app/vlinsert/jsonline/jsonline.go:79 jsonline: cannot read line #1 in /jsonline request: cannot parse JSON: cannot parse number: unexpected char: ","; unparsed tail: ",{\"answers\": 

Expected Behavior:

• One JSON object on each line, no separators

Actual Behavior:

• Lines 2 and after in a batch start with ,

{"answers":[...],"clientIp":"..."}
,{"answers":[...],"clientIp":"..."}

Steps to Reproduce:

• Install the app
• Enable the http sink with the above config
• Make multiple queries in rapid succession so that one batch has more than one record
• Examine the warnings from the log ingestion system and compare the ingested record count with the Technitium query count

The file and console sinks use the same serializer, so they probably have the same problem (not tested).

Root Cause:

• With SkipValidation = true, the reused Utf8JsonWriter writes a separator before each top-level value after the first

Proposed Fix:

• Call Utf8JsonWriter.Reset() after each record is flushed
• I have a one-line fix tested on a branch. Would a PR be acceptable?

[zbalkan]

Hi,

For some reason, I didn't see the notifications. I just saw the issues, including yours, now. Thanks for creating the issue. I'll work on it this weekend and see what I can do.

[Pablo1]

Thank you ! Very grateful for your work on this.

If you accept PRs I have a PR ready to go for you. Your org's contribution guidelines specify that issues needed to be created first and approved. I also have an unrelated PR to "add host.name field and set it to DnsServerDomain".

[zbalkan]

Please try https://github.com/DeltaZulu-OU/LogExporterApp/releases/tag/v3.2.0

[zbalkan]

I also have an unrelated PR to "add host.name field and set it to DnsServerDomain".

May I ask what's the use case here?

[Pablo1]

The Log Exporter app in the Technitium App Store has a syslog target that uses RFC 5424. Each message carries a hostname, which lets you filter logs by host.

I use the DeltaZulu LogExporterApp, which sends NDJSON records over HTTP to VictoriaLogs. Each record has a nameServer field, which contains the IP address that received the query. This address identifies the server, but it is an IP address, not a name. To add a name, I put host.name in the VL-Extra-Fields header of the app configuration. This works when each Technitium instance has its own Log Exporter configuration, because each configuration can have a different hardcoded host.name.

In a cluster, the primary node synchronizes the app configuration to all secondary nodes. A hardcoded host.name then gives the same value for every node. For example, the records from ns2 have the label ns1. Thus, the app must set host.name at runtime, for each record, from the DNS Server Domain of the local node.

In a cluster, the DNS Server Domain of each node is a subdomain of the cluster domain. For example, in the cluster dns-cluster.example.com, the nodes are ns1.dns-cluster.example.com and ns2.dns-cluster.example.com. Thus, each node sends a unique host.name.

With a shared virtual IP address, the nameServer field can no longer identify the node. With VRRP (keepalived), all nodes share one virtual IP address, for example 192.0.2.53. Only one node holds that address at a time, but the active node changes after a failover. Clients send their queries to the virtual IP address, so nameServer has the same value on every node.

[zbalkan]

It makes sense. It's up to you to open a PR then. I can craft something but I may accept a PR as well. As I mentioned in CONRIBUTING, I don't accept PRs in general as free contributions like these are like free puppies. They become my responsibility in the long run. If that's small enough, and it looks like that, it's fine of course.