Typed-nil Schema interface from formulation wrappers causes SIGSEGV in downstream consumers (wrappedSchema.GetType nil pointer dereference)

[jeffreyaven]

Summary

public/formulation/wrappers.go wraps anysdk.Schema values without nil-checking the inner value:

func newWrappedSchemaFromAnySdkSchema(inner anysdk.Schema) Schema {
	return &wrappedSchema{inner: inner}
}

When inner is nil this returns a non-nil interface wrapping a nil pointer (the classic Go typed-nil gotcha). Downstream != nil guards pass, and the first accessor call dereferences the nil inner:

func (w *wrappedSchema) GetType() string {
	r0 := w.inner.GetType() // panics when inner is nil
	return r0
}

All other accessor methods on wrappedSchema (and sibling wrappers constructed the same way) have the same exposure.

Impact

stackql (which pins any-sdk v0.5.3-alpha11, but the code is unchanged at any-sdk HEAD) crashes with a SIGSEGV at plan build time for any EXEC method whose 2xx response schema is an object that does not contain a property matching an exec parameter name (e.g. id). stackql's unary selection deliberately admits param-only columns with a nil schema, passes the nil into formulation.NewColumnDescriptor, and the wrapper converts it into a typed-nil that defeats the nil guard in drm_cfg.go.

In the okta provider alone, 33 operations across 12 services hit this (e.g. activate_user -> UserActivationToken, expire_password_with_temp_password -> tempPassword), and it affects any provider with the same response shape.

Steps to reproduce

No credentials required - the panic occurs at plan build, before auth resolution:

stackql exec "registry pull okta"
stackql exec "EXEC okta.users.users.activate_user @id='dummy', @subdomain='dummy'"

Result:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0xc8 pc=0x1b06dd5]

goroutine 1 [running]:
github.com/stackql/any-sdk/public/formulation.(*wrappedSchema).GetType(...)
	.../any-sdk@v0.5.3-alpha11/public/formulation/wrappers.go:1378
github.com/stackql/stackql/internal/stackql/drm.(*staticDRMConfig).GenerateSelectDML(...)
	.../internal/stackql/drm/drm_cfg.go:725
github.com/stackql/stackql/internal/stackql/primitivegenerator.(*standardPrimitiveGenerator).assembleUnarySelectionBuilder(...)
	.../internal/stackql/primitivegenerator/unary_selection.go:118
github.com/stackql/stackql/internal/stackql/primitivegenerator.(*standardPrimitiveGenerator).AnalyzeUnaryExec(...)
	.../internal/stackql/primitivegenerator/statement_analyzer.go:672

Working control case: EXEC okta.users.users.expire_password @id='dummy', @subdomain='dummy' plans and dispatches fine, because the User response schema contains an id property, so the schema lookup for the projected id column succeeds.

Proposed fix

1. newWrappedSchemaFromAnySdkSchema (and the analogous wrapper factories) should return a nil interface when inner is nil, so existing != nil guards in consumers work as written.
2. Defense in depth: nil-guard the accessor methods on wrappedSchema (return zero values for nil inner), since the wrappers are the public API boundary.

Fixing this at the factory kills the whole class of typed-nil crashes at a single choke point. A companion issue will be raised in stackql/stackql to consume the fix and harden its side (param-only columns pushed with nil schema, and the defeated nil guard).

[jeffreyaven]

Adding a second-provider repro that materially broadens the blast radius: the rebuilt snowflake provider hits this on every EXEC over a non-GET method - 100 mapped EXEC actions across 13 services (resume/suspend/execute/abort/refresh/clone/undrop/rename/swap and friends).

Environment: stackql v0.10.582 (c926a33), Windows and Linux, local file registry.

Repro:

EXEC snowflake.warehouses.warehouses.resume @name = 'WH1', @endpoint = 'myorg-myaccount';

Panic is identical frame for frame to the OP:

• wrappedSchema.GetType() (public/formulation/wrappers.go)
• staticDRMConfig.GenerateSelectDML() (drm_cfg.go)
• standardPrimitiveGenerator.assembleUnarySelectionBuilder() (unary_selection.go)

The crash occurs in the analysis phase, before any wire call.

Trigger matches the OP's diagnosis: every Snowflake action endpoint declares its 2xx response as the shared success envelope ({"status": "Request successfully completed"}) - a schema with no properties matching the projection. Data points that support the typed-nil root cause:

• EXEC over GET-backed methods (databases.get, statements.get_statement_status) works fine on the same binary.
• EXEC over non-GET methods in the k8s provider works fine on the same binary (its mutating operations return the full object schema, not a bare status envelope).
• Inlining the response $ref (materializing the SuccessResponse schema at the operation) does NOT fix it, ruling out ref resolution and pointing at the nil/propertyless schema wrap itself.

Happy to test a patched build - the provider repo has a mock-server integration suite that currently SKIPs two EXEC checks on the panic signature and will assert normally against a fixed binary.