Go version
go1.25
Output of go env
in your module/workspace:
n/a
What did you do?
package main
import (
"fmt"
"io"
"strings"
"github.com/go-json-experiment/json"
"github.com/go-json-experiment/json/jsontext"
)
func main() {
dec := jsontext.NewDecoder(strings.NewReader(`
"hello"
{}
[1,2,3]
`))
for {
var v any
if err := json.UnmarshalDecode(dec, &v); err != nil {
if err == io.EOF {
break
}
panic(err)
}
fmt.Println(v)
}
}
What did you see happen?
It should print:
hello
map[]
[1 2 3]
What did you expect to see?
Instead it prints:
hello
map[]
[1 2 3]
panic: jsontext: unexpected EOF after offset 27
This is a regression from https://go.dev/cl/689919
\cc @neild @jakebailey
Comment From: gopherbot
Change https://go.dev/cl/692175 mentions this issue: encoding/json/v2: fix UnmarshalDecode regression with EOF
Comment From: gabyhelp
Related Issues
- encoding/json: SyntaxError's Offset is wrong after decoding some valid json #32399 (closed)
- encoding/json: UnmarshalText confuses json.Unmarshal #8462 (closed)
- encoding/json: eof error of NewDecoder().Decode() should be same with Unmarshal() #25956
- encoding/json: unmarshal regression for extra data error under goexperiment.jsonv2 #74614 (closed)
- encoding/json/v2: change in Decoder.Token behavior at unexpected EOF #74750 (closed)
- encoding/json: misleading error for end-of-input in an escape sequence #58680
- encoding/json: Unintuitive behavior when using custom UnmarshalText #38947 (closed)
- proposal: encoding/json: option to clear output before unmarshal #49334 (closed)
- encoding/json: do not read beyond } in object #3942 (closed)
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: mrkfrmn
Looks like we just need Damien to review when he returns.
Comment From: croepha
oh, heh, I thought this was the expected behavior and I just couldn't figure out how to use the library properly...
https://stackoverflow.com/questions/79723107/what-is-the-correct-way-to-iterate-through-a-jsonl-reader-with-jsonv2
Comment From: croepha
Is there unit test coverage for this usage pattern?
Comment From: dsnet
Is there unit test coverage for this usage pattern?
Clearly it was lacking one. https://go.dev/cl/692175 adds a test.
In the mean time, you can use github.com/go-json-experiment/json@be8212f5270d1aa58017885231fd65388b6aa132
to avoid the regression. My apologies for the breakage.
Comment From: croepha
No worries, thanks for that ❤️
Comment From: dsnet
\cc @neild @cherrymui, we should make sure we fix this before the Go 1.25 release.
Comment From: dmitshur
@dsnet In general, if something needs to happen before a given release is made, it should be marked as a release-blocker. Otherwise it may be missed. That said, it is probably too late to include this in Go 1.25.0, since it's very late in its release cycle, and this is an experimental package that is still undergoing work. Making this a Go 1.26 release blocker, but please comment if you believe this should potentially block 1.25.0. Thanks.
Comment From: dsnet
I apologize for the late submission, but I believe this should block Go 1.25 as currently jsonv2.UnmarshalDecode
is broken in a streaming manner, which is fairly user-facing function.
Comment From: dmitshur
Given it's still an experimental package and under active development, it's expected that there will be known issues, and it's not viable to block the 1.25 release on that. Still, if you expect this will severely limit user's ability to test out the rest of encoding/json/v2 experimental package, we can consider it further. It should be safe since the fix is isolated to GOEXPERIMENT=jsonv2 only.
A few more questions: Is there a workaround that can be used? Is it acceptable if this is resolved in Go 1.25.1 (early September)?
Comment From: dsnet
Unfortunately, this is fairly user visible. Within days of pulling the upstream change into github.com/go-json-experiment/json
, there were multiple reports of regression (here and here). One workaround is to ignore ErrUnexpectedEOF
along with EOF
, but that would be exposing the user to code to real bugs where they might actually be getting truncated input.
Rather than rolling forward with a fix, perhaps the safer fix is to just revert CL/689919? The fact that the v2 tests didn't detect a more severe regression introduced by the fix shows a lapse in our v2 unit tests.
I apologize for the late request.
Comment From: gopherbot
Change https://go.dev/cl/694495 mentions this issue: Revert "encoding/json: fix extra data regression under goexperiment.jsonv2"
Comment From: dmitshur
Is CL 689919 included in 1.25? I'm not seeing it in Go 1.25 RC 3 nor any of the previous release candidates. It looks like it landed after the tree reopened for Go 1.26 development and was never cherry-picked to Go 1.25's release branch. Is that right?
Trying the repro locally (modified to use encoding/json/v2 and encoding/json/jsontext packages), I see the expected outcome, no "unexpected EOF" panic:
$ go version
go version go1.25rc3 darwin/arm64
$ GOEXPERIMENT=jsonv2 go run /tmp/a.go
hello
map[]
[1 2 3]
Comment From: dsnet
Ah, you're right! Whew. There is no problem then. This does not block Go 1.25.
Sorry for the alarm.
Comment From: dsnet
It seems that the very last commit related to "json" for Go 1.25 is encoding/json: decompose legacy options, which is actually a perfect commit to finalize on.
Comment From: dmitshur
Okay, glad to hear that. Leaving this in Go 1.26 milestone then, and there's plenty of time to resolve it before the 1.26 release freeze. Please be sure to follow the release timeline and the status of the tree more closely in the future, especially when working during the release freeze. Thanks again.