**Description or Expected Behavior/Actual behavior:** Parameters are referenced correctly like so: ``` parameters: - $ref: "../../../parameters/library/section-key.yaml" ``` But the parameters are not being resolved and linted correctly when document validation occurs ``` ERROR validation error: [line 127] path-params - DELETE must define parameter sectionKey as expected by path /library/sections/{sectionKey} ERROR validation error: [line 127] path-params - GET must define parameter sectionKey as expected by path /library/sections/{sectionKey} ERROR validation error: [line 137] path-params - GET must define parameter sectionKey as expected by path /library/sections/{sectionKey}/{tag} ERROR validation error: [line 139] path-params - GET must define parameter sectionKey as expected by path /library/sections/{sectionKey}/refresh ERROR validation error: [line 141] path-params - GET must define parameter sectionKey as expected by path /library/sections/{sectionKey}/search ```

@constantine said: > code samples in readme just ignore that variable

A lot of providers will expose a `insecure = true` config for testing, [example from openstack](https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs#insecure)

Currently, all our targets generate SDKs which use closed enums. When an SDK sees a new value for an enum field, it will typically throw or error in some way. This property of enums is sometimes desirable. However, there are several instance where "open" enums are more desirable and will often aid in building more evolvable APIs. We should support marking enums as open and coalesce new/unrecognised values to some "unknown" member. A proposed approach to modelling this in OpenAPI: A custom `x-speakeasy-enum-fallback` directive specifies an existing member to use as fallback when processing unrecognised values. ``` payment_status: type: string enum: - unknown - created - submitted - successful x-speakeasy-enum-fallback: unknown ``` API authors that want to maintain the original value may decide to declare another field as a plain `type: string` which contains an unmodified copy

The following example was extracted from a customer spec and it was silently broken in some languages because the AST was flattening the union down to one member. We've added a new feature flag to the generator called `sliceUnions` to gradually support this feature across generator targets. The task is to implement support and test generation for PHP. Example: ``` responses: '200': description: A list of events content: application/json: schema: anyOf: - type: array items: $ref: '#/components/schemas/ClickEvents' title: ClickEvents - type: array items: $ref: '#/components/schemas/LeadEvents' title: LeadEvents - type: array items: $ref: '#/components/schemas/SaleEvents' title: SaleEvents ``` As part of fixing this issue: * Add `sliceUnions` to the feature list for php in `features.ts` * Remove the `unions-union-array` entry in php's `features.ts` file under `isTestSkipped`. * Add php to `x-speakeasy-test` list for the `unionOfArraysPost` operation in `uber.yaml` (provided test generation is implemented for php)

## Description A customer reported that they're not able to override a generated Go SDK's server for an operation object that specified its own `servers` list. The OAS in question is [this one](https://github.com/Kong/sdk-konnect-go/blob/68361d15ff1e03ac1fb624ccf2a626468e897b23/openapi.yaml#L3910). Specifically calling attention to the servers defined on lines 13-17: ``` openapi: 3.1.0 info: # ... info ... servers: - url: https://global.api.konghq.com - url: https://us.api.konghq.com - url: https://eu.api.konghq.com - url: https://au.api.konghq.com paths: # ... paths ... ``` And an endpoint, like `/v3/authenticate/{organizationLoginPath}` , that defines its own `server` list: ``` /v3/authenticate/{organizationLoginPath}: get: operationId: authenticate-sso summary: SSO Callback description: Callback for authenticating via an organization's IdP parameters: - name: organizationLoginPath in: path description: The login path for the organization. required: true schema: type: string - name: return_to in: query description: Return destination for the callback. schema: type: string responses: '302': description: Found '400': $ref: '#/components/responses/IdentityBadRequest ``` ``` ' '401': $ref: '#/components/responses/IdentityUnauthenticated' # Route-level servers defn servers: - url: https://global.api.konghq.com/ tags: - Authentication ``` The issue is that, when the user creates a new SDK object @ runtime with an arbitrary server URL specified, the operations that have their own `servers` defined are not directed to the runtime-specified URL. ## Example For example, with an (Go) SDK instance defined like so: ``` sdk := sdk.New( token, sdkkonnectgo.WithServerURL(testKonnectServerURL) ) ``` `sdk.Consumers.ListConsumers` - The request goes to `testKonnectServerURL` `sdk.Authentication.AuthenticateSso` - The request goes to the only defined server in the OAS operation defn ## Links: ### Slack Threads: * **#dev-sdk:** [https://speakeasyapi.slack.com/archives/C05JZT0RADP/p1731530467628319](https://speakeasyapi.slack.com/archives/C05JZT0RADP/p1731530467628319) * **#customer-support-feed:** [https://speakeasyapi.slack.com/archives/C04QKUFJ0N9/p1731523198603859](https://speakeasyapi.slack.com/archives/C04QKUFJ0N9/p1731523198603859) ### GitHub * OAS:

-

**Description or Expected Behavior/Actual behavior:** Allow the SDK to pass a reference to itself in the hook context, specifically to support our PDF request splitting functionality. Would like to create new `Request` objects and pass them to `sdk.general.partition_async` directly from within the hook. To do this effectively, the SDK should pass a reference to itself within the hook context. This would ensure that all configurations and logic within the SDK are consistently applied to these additional requests, streamlining the process and reducing the risk of errors. **Customer Description (if applicable):** Original Message: Hey all! I'd like to request that the sdk pass a reference to itself in the hook content. This is for our pdf request splitting which has a ­BeforeRequestHook like so: • Open the request. If the file param is a pdf, break it into N smaller files. Send each of these as a new httpx request. Return the last file for the SDK to process. Since we added these extra httpx calls underneath the SDK code, we have to copy over the retry config, and we'll miss out on any other changes to this logic. What I'd like to do is create a few new Request objects, and send the to sdk.general.partition_async from within the hook. The requester also referenced additional attachments: ­ split_pdf_hook.py ``` def before_request( ``` **Replication Steps (for bugs)/Use Case (for features):** They have implemented a `BeforeRequestHook` for handling PDF file uploads that operates as follows: * Upon receiving a request, if the `file` parameter is a PDF, it is split into `N` smaller files. * `N-1` of these files are sent as new `httpx` requests. * The last file is returned for the SDK to process as usual. Currently, because these additional `httpx` requests are being made outside of the SDK's original context, we are required to manually copy over the retry configuration and any other relevant settings. This approach risks missing future changes to the SDK's request handling logic. **Risks/Other Notes:**

@sagar said: > We do support `Retry-After` in the spec [https://www.speakeasy.com/docs/runtime/retries#respecting-retry-after](https://www.speakeasy.com/docs/runtime/retries#respecting-retry-after) but only in TS i think. I’ll see if we can get it added to golang

-