json: unsupported type: chan string #388
Comments
JensErat
added a commit
to JensErat/loki
that referenced
this issue
Nov 22, 2019
While developing another fix, I stumbled upon grafana#1309 as a newly written unit test (with multiple key-value pairs in a map) was flaky. While JSON does not [strictly define an order on records in a map][RFC8259], but practical operations with a logging tool pretty much require it (although of course grep for JSON is jq, not grep...). Also, the key value output format is already sorted. Switching to sorted output in jsoniter is pretty easy. As of today, it still has a [bug] though, for which I already provided a [fix]. I propose accepting that rare case where invalid types can occur from msgpack output (can this even happen?) and re-enable the failing test case as soon as the upstream PR is merged. [RFC8259]: https://tools.ietf.org/html/rfc8259#section-4 [bug]: json-iterator/go#388 [fix]: json-iterator/go#422 Signed-off-by: Jens Erat <email@jenserat.de>
cyriltovena
pushed a commit
to grafana/loki
that referenced
this issue
Nov 26, 2019
* fluent-bit: fix variable spelling mistake Signed-off-by: Jens Erat <email@jenserat.de> * fluent-bit: sort JSON map While developing another fix, I stumbled upon #1309 as a newly written unit test (with multiple key-value pairs in a map) was flaky. While JSON does not [strictly define an order on records in a map][RFC8259], but practical operations with a logging tool pretty much require it (although of course grep for JSON is jq, not grep...). Also, the key value output format is already sorted. Switching to sorted output in jsoniter is pretty easy. As of today, it still has a [bug] though, for which I already provided a [fix]. I propose accepting that rare case where invalid types can occur from msgpack output (can this even happen?) and re-enable the failing test case as soon as the upstream PR is merged. [RFC8259]: https://tools.ietf.org/html/rfc8259#section-4 [bug]: json-iterator/go#388 [fix]: json-iterator/go#422 Signed-off-by: Jens Erat <email@jenserat.de> * fluent-bit: properly convert []byte to string Recently, a regression was introduced that no longer ran a deep conversion of `[]byte` to `string` unless a label map was supplied. This commit fixes this by running the string conversion recursively, also removing the need of applying the conversion function again during label map stage. This change has two minor side effects: - Some test cases had to be moved, as string conversion happens much earlier now. - Invalid characters do not result in the whole label being ignored any more, but are replaced by the unicode placeholder character now. I'd consider this an improvement, making both debugging much easier ("why is that value suddenly missing?") and preserving as much information as possible. Signed-off-by: Jens Erat <email@jenserat.de>
rchincha
added a commit
to rchincha/zot
that referenced
this issue
Jan 7, 2020
older versions of json-iterator appear to have an issue with maps. We are most certainly hitting this panic with maps. https://github.com/anuvu/zot/blob/master/pkg/api/routes.go#L898 On the json-iterator/go side, json-iterator/go@acfec88 json-iterator/go#388
zhenzou
pushed a commit
to zhenzou/jsoniter
that referenced
this issue
Feb 2, 2022
pass nested error in compatible configuration, fixes json-iterator#388
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While replacing "encoding/json" with json-iterator, I encountered that json.Marshal used to throw an error when a map of this form was provided:
testMap["key"] = make(chan, string)error returned: json: unsupported type: chan stringbut, json-iterator does not return any such error on encountering this kind of data. json-iterator should have similar behaviour as old json.Marshal
The text was updated successfully, but these errors were encountered: