panic(err) on parseInt64 failure while sorting !!int values

Error message

panic(err) on parseInt64 failure while sorting !!int values

What it means

The sort operator's compare function panics when sort_by/sortKeys encounters two nodes both tagged !!int whose string value cannot be parsed as a 64-bit integer (parseInt64 in operator_sort.go:161-167). Rather than falling back to string comparison like the datetime branch does, it panics inside sort.Less, crashing the whole process. The !!int tag can be present on values that are not machine-parseable int64 (e.g. values tagged by a decoder or custom type tags), so the tag check is an unreliable guard.

Source

Thrown at pkg/yqlib/operator_sort.go:163

			log.Warningf("Could not parse time %v with layout %v for sort, sorting by string instead: %v", lhs.Value, layout, err)
			return strings.Compare(lhs.Value, rhs.Value)
		}
		rhsTime, err := parseDateTime(layout, rhs.Value)
		if err != nil {
			log.Warningf("Could not parse time %v with layout %v for sort, sorting by string instead: %v", rhs.Value, layout, err)
			return strings.Compare(lhs.Value, rhs.Value)
		}
		if lhsTime.Equal(rhsTime) {
			return 0
		} else if lhsTime.Before(rhsTime) {
			return -1
		}

		return 1
	} else if lhsTag == "!!int" && rhsTag == "!!int" {
		_, lhsNum, err := parseInt64(lhs.Value)
		if err != nil {
			panic(err)
		}
		_, rhsNum, err := parseInt64(rhs.Value)
		if err != nil {
			panic(err)
		}
		if lhsNum < rhsNum {
			return -1
		} else if lhsNum > rhsNum {
			return 1
		}
		return 0
	} else if (lhsTag == "!!int" || lhsTag == "!!float") && (rhsTag == "!!int" || rhsTag == "!!float") {
		lhsNum, err := strconv.ParseFloat(lhs.Value, 64)
		if err != nil {
			panic(err)
		}
		rhsNum, err := strconv.ParseFloat(rhs.Value, 64)
		if err != nil {

View on GitHub (pinned to 8b5af0694b)

Solutions

Inspect the array being sorted with `yq '.[] | tag'` and find values tagged !!int that are not plain decimal int64 literals.
Correct the offending data at the source, or coerce to float/string before sorting: `sort_by(.val | tag="!!str")` or `sort_by(.val | tonumber)` style coercion.
Pre-filter or fix oversized values: convert to !!float so the ParseFloat branch is used, or to !!str for lexicographic sorting.
If this is a bug in your data pipeline (bad tag assignment), fix the decoder/expression that forces the !!int tag.
Upgrade yq: newer versions may gracefully fall back to string comparison on parse failure, as already done for datetimes.

Example fix

# before
yq 'sort_by(.id)' data.yaml   # panics: .id = 99999999999999999999 tagged !!int

# after
yq 'sort_by(.id | from_yaml | tag="!!str")' data.yaml
# or fix the data
yq '.[] |= (.id | tag="!!float")' data.yaml | yq 'sort_by(.id)'

Defensive patterns

Strategy: validation

Validate before calling

# validate all !!int values parse as int64 before sorting
yq '.[] | select(tag == "!!int") | select(test("^-?[0-9]+$") | not) ' data.yaml
# empty output => safe to sort

Type guard

// Go: guard before compare
func isParseableInt64(s string) bool {
    _, err := strconv.ParseInt(s, 10, 64)
    return err == nil
}

Try / catch

// yqlib hosts: recover the sort panic
func safeSort() (err error) {
    defer func() { if r := recover(); r != nil { err = fmt.Errorf("sort panic: %v", r) } }()
    // ... run yq sort_by ...
    return nil
}

Prevention

Check numeric tags with `tag` operator before sort_by on untrusted data
Avoid forcing !!int tags onto large or exotic literals; use !!float or !!str
Normalize YAML 1.1 hex/underscore integers to decimal before sorting
Wrap embedded yqlib calls in recover() since sort panics cannot be returned as errors

When it happens

Trigger: Running sort or sort_by (e.g. `yq 'sort_by(.key)'`) where at least two elements in the array are tagged !!int but their .Value string is not a valid int64: values exceeding int64 range (e.g. 99999999999999999999), strings like '1_000' or '0x1F' that were tagged !!int by an input format decoder, or nodes whose tags were forced with `tag: !!int`.

Common situations: Sorting arrays parsed from JSON/YAML containing very large integers (IDs, snowflakes, IPv4-as-int) that overflow int64; data re-tagged via yq's tag operator; CSV/properties inputs where everything is string but tags were coerced; sorting mixed-size numbers across architectures.

Related errors

AI-assisted analysis of mikefarah/yq@8b5af0694b (2026-09-05). Data as JSON: /api/errors/7ab20247fa9d573d. Report an issue: GitHub.