[Go] lazy serializer init silently swallows createSerializer error in getTypeInfo

[ayush00git]

Bug

In go/fory/type_resolver.go line 1018, the lazy-serializer-initialization path inside getTypeInfo discards the error returned by createSerializer:

serializer, err := r.createSerializer(value.Type(), false)
if err != nil {
    fmt.Errorf("failed to create serializer: %w", err) // result unused — error lost
}
info.Serializer = serializer  // nil serializer stored in cache
return info, nil              // false success returned to caller

The fmt.Errorf result is never used (detected by `go vet`). On failure, a `nil` serializer is stored in both `typesInfo` and typePointerCache, and the function returns `(info, nil)` — hiding the failure from all callers. This leads to a nil-pointer panic or silent data corruption far from the actual failure site.

All sibling call sites in the same file propagate the error correctly (e.g. `getSerializerByType` at line 942).

Fix

if err != nil {
    return nil, fmt.Errorf("failed to create serializer: %w", err)
}

Regression test

A white-box test seeds `typesInfo` with a nil-serializer entry for `**int` (pointer-to-pointer is explicitly rejected by createSerializer), calls `getTypeInfo`, and asserts:

• a non-nil error is returned
• no nil-serializer entry is left in `typePointerCache`

Detected by

go vet: type_resolver.go:1018:5: result of fmt.Errorf call not used