feat(gooddata-sdk): [AUTO] Add ExecutionResultLimitBreak schema for partial results

[yenkins-admin]

Summary

Added ExecutionResultLimitBreak SDK class and limit_breaks property on ExecutionResult. The new class models the ExecutionResultLimitBreak schema (limit, limit_type, value) with a from_dict() classmethod that maps camelCase API keys to snake_case fields. ExecutionResult now reads the optional limitBreaks list from the API response (stored as an additional property under its camelCase key) and exposes it as limit_breaks → list[ExecutionResultLimitBreak], returning [] when absent. The class is re-exported from gooddata_sdk.init.

Impact: new_feature | Services: gooddata-afm-client

Source commits (gdc-nas):

• 71bb41a by Mike Zelenskij — Merge pull request #22984 from gooddata/c.mze-cq-2334

Files changed

• packages/gooddata-sdk/src/gooddata_sdk/compute/model/execution.py
• packages/gooddata-sdk/src/gooddata_sdk/__init__.py
• packages/gooddata-sdk/tests/compute/test_bare_execution_response.py
• packages/gooddata-sdk/tests/compute/test_execution_result_limit_break.py
• packages/gooddata-sdk/tests/compute/fixtures/.gitkeep

Agent decisions

Decisions (3)

placement of limitBreaks on ExecutionResult vs ExecutionResultMetadata — Add limitBreaks as a field on ExecutionResult (the top-level result object)

• Alternatives: Add to ExecutionResultMetadata where dataSourceMessages lives, Add to ExecutionResultGrandTotal
• Why: The description 'Absent when the result is complete' is a top-level result concern. The diff hunk context places limitBreaks as a sibling to data/paging/grandTotals-level fields.

accessing limitBreaks from undeclared model field — Use result.get('limitBreaks') with camelCase key on the ModelNormal instance

• Alternatives: Use result.get('limit_breaks') — would return None always, Update gooddata-api-client model — not allowed (auto-generated)
• Why: change_keys_js_to_python only converts keys present in attribute_map; unknown keys are stored as-is with their original JSON camelCase name in _data_store.

absent limitBreaks returns empty list vs None — Return [] when limitBreaks absent from API response

• Alternatives: Return None to signal absence explicitly
• Why: Consistent with other list properties on ExecutionResult which never return None; callers can use len(result.limit_breaks) == 0 without None guards.

Assumptions to verify (3)

• The diff's second hunk targets ExecutionResult not ExecutionResultMetadata — inferred from description semantics ('partial result') and sibling field placement.
• gooddata-api-client ModelNormal stores unknown response fields with camelCase JSON key names in _data_store (verified via change_keys_js_to_python source code).
• ty check exits non-zero with 14 pre-existing errors in files not touched by this change (pyarrow optional-import, filter.py, catalog_service_base.py, export/service.py). None introduced by this PR.

Risks (2)

• If limitBreaks is on ExecutionResultMetadata rather than ExecutionResult, limit_breaks will always be []. Integration cassette with active limits will catch this.
• If the generated client normalises the field key to snake_case (limit_breaks) rather than camelCase (limitBreaks), result.get('limitBreaks') returns None always. A cassette with actual limit breaks will surface this.

Layers touched (3)

• entity_model — Added ExecutionResultLimitBreak @define class and limit_breaks property to ExecutionResult
  • packages/gooddata-sdk/src/gooddata_sdk/compute/model/execution.py
• public_api — Exported ExecutionResultLimitBreak
  • packages/gooddata-sdk/src/gooddata_sdk/__init__.py
• tests — Parametrized unit tests for from_dict() and integration test for limit_breaks property
  • packages/gooddata-sdk/tests/compute/test_bare_execution_response.py
  • packages/gooddata-sdk/tests/compute/test_execution_result_limit_break.py

OpenAPI diff

--- a/gooddata-afm-client.json
+++ b/gooddata-afm-client.json
@@ -2995,6 +3057,30 @@
+      "ExecutionResultLimitBreak": {
+        "description": "Describes a limit that was broken, resulting in partial data being returned.",
+        "properties": {
+          "limit": {
+            "description": "The configured threshold value.",
+            "format": "int64",
+            "type": "integer"
+          },
+          "limitType": {
+            "description": "Type of the limit that was broken, e.g. \"rowCount\".",
+            "type": "string"
+          },
+          "value": {
+            "description": "The actual value that triggered the limit; null when it cannot be determined exactly.",
+            "format": "int64",
+            "type": "integer"
+          }
+        },
+        "required": [ "limit", "limitType" ],
+        "type": "object"
+      },
@@ -3002,6 +3088,13 @@
           "limitBreaks": {
+            "description": "Limits that were broken during result computation, causing the result to be partial. Absent when the result is complete.",
+            "items": {
+              "$ref": "#/components/schemas/ExecutionResultLimitBreak"
+            },
+            "type": "array"
+          },

Workflow run

---

Generated by SDK OpenAPI Sync workflow

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.03%. Comparing base (38b0798) to head (b6a8695).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1614      +/-   ##
==========================================
+ Coverage   79.01%   79.03%   +0.02%     
==========================================
  Files         231      231              
  Lines       15619    15636      +17     
==========================================
+ Hits        12341    12358      +17     
  Misses       3278     3278              

☔ 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.