feat(gooddata-sdk): [AUTO] Add retrieveResultBinary endpoint; remove Arrow formats from retrieveResult

[yenkins-admin]

Summary

Added Execution.read_result_arrow() method to the SDK's Execution class, delegating to the already-implemented BareExecutionResponse.read_result_arrow(). Also added two new unit tests that exercise the delegation path through Execution. No other layers needed changes: the API client already had retrieve_result_binary, BareExecutionResponse.read_result_arrow() was already implemented and tested, and all relevant classes were already exported from gooddata_sdk/__init__.py.

Impact: new_feature | Services: gooddata-afm-client

Files changed

• packages/gooddata-sdk/src/gooddata_sdk/compute/model/execution.py
• packages/gooddata-sdk/tests/compute/test_bare_execution_response.py

Agent decisions

Decisions (3)

where to expose read_result_arrow() — Add read_result_arrow() to Execution as a thin delegation to bare_exec_response.read_result_arrow()

• Alternatives: Add a service-level method on ComputeService, Leave it only on BareExecutionResponse and document the accessor
• Why: Execution already delegates read_result() and cancel() to BareExecutionResponse the same way. The gooddata-pandas package accesses it via execution.bare_exec_response.read_result_arrow() which is not a clean public API. Adding it directly on Execution matches the existing pattern and lets callers use execution.read_result_arrow() consistently.

not adding a new service method on ComputeService — No ComputeService change; the binary read is per-execution, not a standalone service call

• Alternatives: Add ComputeService.retrieve_result_binary(workspace_id, result_id)
• Why: ComputeService.for_exec_def() returns an Execution. Result reading is modeled as a method on the Execution/BareExecutionResponse, not on the service. retrieve_result_cache_metadata() is an exception because it takes a result_id independently; read_result_arrow() always follows an Execution.

not modifying init.py — No changes to public exports

• Why: Execution and BareExecutionResponse are already exported. The new method is just an addition to an already-exported class.

Assumptions to verify (3)

• The pre-existing BareExecutionResponse.read_result_arrow() implementation (using call_api with /binary path and application/vnd.apache.arrow.stream Accept header) is correct for the new retrieveResultBinary endpoint.
• The type-check errors from ty check are all pre-existing environment issues (missing cattrs, requests, pyarrow site-packages) and not introduced by this change.
• gooddata-pandas callers that use execution.bare_exec_response.read_result_arrow() remain fully backward-compatible; the new Execution.read_result_arrow() is additive.

Risks (2)

• No integration tests added (the feature involves binary Arrow data over HTTP which requires a live server cassette); the existing unit tests on BareExecutionResponse.read_result_arrow() are sufficient coverage for the pure delegation.
• If the API server still returns arrow data on the old /result endpoint (before the OpenAPI change is deployed), callers using read_result_arrow() on the new binary endpoint may get errors — this is a server-side concern, not an SDK concern.

Layers touched (2)

• entity_model — Added read_result_arrow() delegation method to Execution class
  • packages/gooddata-sdk/src/gooddata_sdk/compute/model/execution.py
• tests — Added _make_execution() factory and two test functions for Execution.read_result_arrow()
  • packages/gooddata-sdk/tests/compute/test_bare_execution_response.py

Source commits (gdc-nas)

• 81eb97a Merge pull request #21382 from gooddata/dho/cq-104-arrow-api-2

OpenAPI diff

diff --git a/microservices/afm-exec-api/src/test/resources/openapi/open-api-spec.json
@@ retrieveResult response: remove Arrow media types @@
@@ -6314,9 +6314,7 @@
                 "schema" : { "$ref" : "#/components/schemas/ExecutionResult" }
-              },
-              "application/vnd.apache.arrow.file" : { },
-              "application/vnd.apache.arrow.stream" : { }
+              }
@@ +new endpoint: retrieveResultBinary @@
+    "/api/v1/actions/workspaces/{workspaceId}/execution/afm/execute/result/{resultId}/binary" : {
+      "get" : {
+        "description" : "(BETA) Gets a single execution result as an Apache Arrow IPC File or Stream format.",
+        "operationId" : "retrieveResultBinary",
+        "parameters" : [ { workspaceId path }, { resultId path }, { "in" : "header", "name" : "X-GDC-CANCEL-TOKEN", "required" : false, "schema" : { "type" : "string" } } ],
+        "responses" : {
+          "200" : { "content" : {
+            "application/vnd.apache.arrow.file" : { "schema" : { "format" : "binary", "type" : "string" } },
+            "application/vnd.apache.arrow.stream" : { "schema" : { "format" : "binary", "type" : "string" } }
+          }, "description" : "Execution result was found and returned." }
+        },
+        "summary" : "(BETA) Get a single execution result in Apache Arrow File or Stream format",
+        "tags" : [ "Computation", "actions" ],
+        "x-gdc-security-info" : { "permissions" : [ "VIEW" ] }
+      }
+    },

Workflow run

---

Generated by SDK OpenAPI Sync workflow

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.66%. Comparing base (37d0593) to head (3b9ffeb).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1557   +/-   ##
=======================================
  Coverage   78.66%   78.66%           
=======================================
  Files         230      230           
  Lines       15405    15407    +2     
=======================================
+ Hits        12118    12120    +2     
  Misses       3287     3287           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.