mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-09-07 00:01:49 +00:00
* fix(ai): stop breaking OpenAI-compatible gateways in workspace AI settings The workspace/instance AI proxy sent credentials in a shape that OpenAI-compatible and Anthropic-compatible gateways reject, while the same resource worked in an AI agent step: - `is_azure` treated *any* OpenAI base URL other than api.openai.com as Azure, so a gateway got the Azure `api-key` header instead of `Authorization: Bearer` and an `/openai/v1/`-rewritten path. Match on the host instead. - The Anthropic proxy sent both `authorization: Bearer` and `X-API-Key`. Gateways reject ambiguous credentials; send only the header the endpoint expects, matching `get_auth_headers` and the agent-step path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ai): match Azure on the endpoint and let resource headers own auth Review follow-ups: - Azure OpenAI reached through a custom domain keeps its `/openai/deployments` path, which `openai_azure_base_path` documents; match on it so those instance-wide settings are not reclassified as plain OpenAI-compatible. - Cover the sovereign-cloud API Management suffixes and FQDNs with a trailing dot. - A resource that supplies its own `authorization`/`x-api-key` header now suppresses the built-in one. Outgoing headers are appended rather than replaced, so both credentials used to travel, which is exactly what gateways reject; this is the escape hatch for endpoints wanting bearer auth. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ai): give the agent step the same resource-header credential rule Review round follow-ups: - `ai_executor` appended the query builder's credential header alongside the resource's, so an AI agent step still sent two credentials where the proxy now sends one. Both paths share `resource_owns_credentials`/`CREDENTIAL_HEADERS`; non-credential headers such as `anthropic-version` are kept. - Cover the OpenAI-compatible proxy's suppression branch with a test. - Match the Azure deployments path case-insensitively, like the host. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ai): scope the credential override to the header the provider uses A resource header now replaces the built-in credential only when it is the same header the provider authenticates with, or an `authorization` one (which every endpoint reads as the credential). Matching any credential-shaped header let an OpenAI-compatible resource's `x-api-key` routing header suppress the bearer token. Google AI's `x-goog-api-key` joins the list so the override reaches that provider too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(ai): share credential and trailing header assembly across AI paths The proxy and the AI agent step each assembled outbound headers themselves, so this fix had to be applied at three sites and the rules could drift apart silently. Two pieces move into `proxy`: - `credential_header` picks the credential to send, applying the resource override. `authorization` carries a bearer token and every other credential header carries the raw key, which holds for every provider. - `common_outbound_headers` yields Windmill's own headers then the resource's, the tail every outbound request shares. A resource resolves to an api key or an OAuth token, never both, so selecting one drops the branch that could emit two `authorization` headers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ai): keep OAuth tokens on the bearer header An OAuth resource resolves to an access token, which every provider reads from `authorization` — Azure OpenAI accepts api keys in `api-key` but Entra ID tokens only as a bearer. Sending it in the provider's key header left Azure OpenAI and Foundry Claude OAuth resources unauthenticated. Also covers the credential-override narrowing: a credential-shaped header the provider does not authenticate with is an ordinary header and must not suppress the built-in credential. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Windmill Backend
This folder holds all backend components, the src/ folder only contains files used to build the "root" binary.
Components
| name | description |
|---|---|
| windmill-api | The API server, exposing functionality to other components and the frontend |
| windmill-audit | Contains audit functionality, allowing different components to record important actions |
| windmill-common | Common code shared by all crates |
| windmill-queue | Contains job & flow queuing functionality, commonly written to by the API server and read from by workers |
| windmill-worker | The worker. Used to process and execute flows & jobs. |
| parsers | Contains code to parse signatures in different langauges. |
Compile sqlx for offline ci
cargo sqlx prepare --workspace -- --bin windmill --features enterprise