sharan-s2k opened a new pull request, #66956: URL: https://github.com/apache/airflow/pull/66956
Problem The Execution API uses a two-step token model: the scheduler issues a longer-lived workload JWT for queued work; when the worker calls PATCH …/run, the server returns a short-lived execution JWT in the Refreshed-API-Token response header. The Python Task SDK already updates its Authorization header from that header on every response. The Go SDK’s WithBearerToken path set a static Authorization header and never applied Refreshed-API-Token, so after /run the client could keep sending the workload token on later calls (e.g. heartbeat, state updates), which does not match the server’s scope rules. Solution Register a Resty response middleware on the bearer-scoped client that, when Refreshed-API-Token is present, updates the default Authorization: Bearer … header for subsequent requests (same idea as the Task SDK’s _update_auth). Add a small unit test that proves the second request uses the refreshed token after the first response sets the header. Tighten the Execution API security.py module docstring so the workload scope description matches routes that allow both token:execution and token:workload (e.g. /run). Testing go test ./go-sdk/pkg/api/... (or from go-sdk: go test ./pkg/api/...) Related Aligns Go workers with the existing two-token / refresh behavior described for the Execution API and implemented for the Python client. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
