support proto serialization

[krehermann]

I want to record responses from the JD in the operation report, and it's failing on IsSerializable.

All proto messages are, by defn, serializable, so add support

[changeset-bot]

⚠️ No Changeset found

Latest commit: f98c206

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

👋 krehermann, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

[Copilot]

Pull Request Overview

This PR adds support for Protocol Buffer (protobuf) message serialization to the IsSerializable validation function. The change recognizes that all protobuf messages are inherently serializable and should be treated as such in the validation logic.

• Added protobuf message detection to the IsSerializable function
• Included a new test case to verify protobuf serialization support
• Reorganized imports to follow Go conventions

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
operations/validation.go	Added protobuf message detection logic and updated function documentation
operations/validation_test.go	Added test case for protobuf message serialization and reorganized imports

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The function doesn't handle nil pointer values correctly. If v represents a nil pointer to a proto message, v.Type() will return the pointer type but the check may fail. Consider adding a nil check and handling the case where v.Kind() == reflect.Ptr && v.IsNil().

Suggested change

	protoMsgType := reflect.TypeOf((*proto.Message)(nil)).Elem()
	protoMsgType := reflect.TypeOf((*proto.Message)(nil)).Elem()
	// Handle nil pointer: check the type the pointer points to
	if v.Kind() == reflect.Ptr && v.IsNil() {
	elemType := v.Type().Elem()
	return elemType.Implements(protoMsgType) || reflect.PointerTo(elemType).Implements(protoMsgType)
	}

[Copilot]

The proto message check should be placed after the nil value check but before dereferencing pointers to maintain consistent logic flow. Currently, it may incorrectly handle pointer-to-proto cases that are checked later in the function.

[Copilot]

Pull Request Overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The reflect.TypeOf((*proto.Message)(nil)).Elem() call is executed on every invocation. Consider extracting this to a package-level variable to avoid repeated reflection operations.

[graham-chainlink]

Hmm i dont think this is enough, even though this serialized without error, it doesnt mean we dont have data lost.

My understanding that for protos , we should at least be using "google.golang.org/protobuf/encoding/protojson" as using encoding/json will cause data lost as it doesnt know how to handle proto message.