Skip to content

Conversation

@jbw976
Copy link
Member

@jbw976 jbw976 commented Feb 8, 2026

Description of your changes

Similar to the python SDK update in crossplane/function-sdk-python#193, this PR updates the Go SDK to support advertised capabilities and required schemas, which were added to Crossplane in crossplane/crossplane#7022.

I have:

  • Read and followed Crossplane's contribution process.
  • Run make reviewable to ensure this PR is ready for review.

How has this code been tested

I have tested these changes locally in a function and verified that requesting schemas works as expected and capabilities are being advertised as expected.

…nd required schemas

Signed-off-by: Jared Watts <jbw976@gmail.com>
Signed-off-by: Jared Watts <jbw976@gmail.com>
Signed-off-by: Jared Watts <jbw976@gmail.com>
Signed-off-by: Jared Watts <jbw976@gmail.com>
@coderabbitai
Copy link

coderabbitai bot commented Feb 8, 2026

📝 Walkthrough

Walkthrough

These changes introduce a capability advertisement and schema management system to the function execution protocol. New message types (SchemaSelector, Schema, Capability enum) are added to both v1 and v1beta1 protocol buffers, enabling functions to declare supported features and request OpenAPI schemas. Corresponding Go helper functions facilitate capability checking and schema retrieval/declaration, with comprehensive test coverage.

Changes

Cohort / File(s) Summary
Protocol Buffer Definitions
proto/v1/run_function.proto, proto/v1beta1/run_function.proto
Added Capability enum with values for feature advertisement and SchemaSelector/Schema messages for schema identification and representation. Extended RunFunctionRequest with required_schemas field, RequestMeta with capabilities field, and Requirements with schemas field. Minor comment normalization in Resource.ready field.
Request Package Helpers
request/request.go, request/request_test.go
Introduced AdvertisesCapabilities, HasCapability, and GetRequiredSchema functions to query capability support and retrieve required schemas from requests. Comprehensive test suites validate behavior across multiple scenarios.
Response Package Helpers
response/response.go, response/response_test.go
Added RequireSchema function to declare required schemas in function responses with proper initialization. Tests verify correct behavior and improved error handling in test utilities.
SDK Test Formatting
sdk_test.go
Modified JSON output to use json.Compact for compacted representation instead of raw string output.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: adding support for advertised capabilities and required schemas across multiple files, and meets the 72-character limit.
Description check ✅ Passed The description is directly related to the changeset, referencing specific PRs and explaining the purpose of supporting advertised capabilities and required schemas.
Breaking Changes ✅ Passed This pull request introduces only additive changes to the public Go API with no breaking modifications.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments
response/response_test.go (1)

157-231: Well-structured test — nice coverage of the two key paths. 👍

The table-driven structure, PascalCase naming, and use of protocmp.Transform() all look great. Thanks for covering both the fresh-response and existing-requirements scenarios!

One thought: would it be worth adding a case where Schemas already has an entry (e.g., to verify a second schema is appended without clobbering the first)? That would exercise the "map already initialized" branch more explicitly. Totally up to you whether that's worth the extra case.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment on lines +168 to +173
for _, c := range req.GetMeta().GetCapabilities() {
if c == capability {
return true
}
}
return false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think slices.Contains(req.GetMeta().GetCapabilities(), capability) is the hip new way to do this.

https://pkg.go.dev/slices#Contains

// Use AdvertisesCapabilities to check whether
// Crossplane advertises its capabilities at all. If it doesn't, HasCapability
// always returns false even for features the older Crossplane does support.
func HasCapability(req *v1.RunFunctionRequest, capability v1.Capability) bool {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func HasCapability(req *v1.RunFunctionRequest, capability v1.Capability) bool {
func HasCapability(req *v1.RunFunctionRequest, cap v1.Capability) bool {

Nit: doesn't need a long var name given the descriptive type name.

// a protobuf Struct, or nil if the schema was not found. Returns nil both when
// Crossplane has not yet resolved the requirement and when it was resolved but
// the schema wasn't found. To distinguish between these cases, check whether
// the name exists in req.GetRequiredSchemas().
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth adding GetRequiredSchemas (plural)? I'm on the fence. It'd be nice for documentation purposes and to stay consistent with GetRequiredResources but I imagine it wouldn't actually do much.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To distinguish between these cases, check whether the name exists in req.GetRequiredSchemas().

It occurs to me that a better UX would be for this to return (*structpb.Struct, bool) with the bool indicating whether the resource was resolved. I'd like to stay consistent with GetRequiredResource though. I could be convinced a better UX is worth a breaking change here, given this SDK is pre-1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants