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

[yenkins-admin]

Summary

Added ExecutionResultLimitBreak class to represent partial-data limit information from the new ExecutionResultLimitBreak OpenAPI schema. The class uses @attrs.define with fields limit (int), limit_type (str), and optional value (int|None), plus a from_dict() factory that maps camelCase API keys to snake_case. It is exported from gooddata_sdk.init. Users access limit breaks via result.metadata.get('limitBreaks') and parse each entry with ExecutionResultLimitBreak.from_dict(). Unit tests (4 parametrized cases) and an integration test with VCR cassette reference were written.

Impact: new_feature | Services: afm

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/limit_break.py
• packages/gooddata-sdk/src/gooddata_sdk/__init__.py
• packages/gooddata-sdk/tests/compute/test_execution_result_limit_break.py
• packages/gooddata-sdk/tests/compute/test_execution_limit_break_integration.py

Agent decisions

Decisions (3)

execution.py not modified — Standalone ExecutionResultLimitBreak class; limit breaks accessed via result.metadata raw dict

• Alternatives: Add limit_breaks property to ExecutionResult in execution.py, Subclass ExecutionResult in a new file
• Why: execution.py is in SHARED_CORE_BLOCKED_FOR_WRITE and has pre-existing ty errors. Scoping ty check to a modified execution.py would surface those baseline errors, which cannot be fixed without out-of-scope changes. Standalone class + raw dict access is the safe pattern until api-client is regenerated and execution.py is unlocked.

from_dict factory over Base.from_api — Custom from_dict() classmethod reading limitType camelCase to limit_type snake_case

• Alternatives: Use Base.from_api() with cattrs structuring
• Why: Generated client has no ExecutionResultLimitBreak model yet. from_dict reads directly from raw API dict, handles the camelCase rename, and guards optional value with .get().

integration test cassette strategy — Write test referencing fixtures/test_execution_result_limit_break.yaml; needs recording against server with low row-count limit

• Alternatives: Skip integration test, Extend existing table test cassette
• Why: new_feature sdk_impact requires an integration test. Cassette will be recorded by the pipeline recorder against staging with appropriate limit config.

Assumptions to verify (3)

• limitBreaks is added to ExecutionResultMetadata (confirmed by diff context around dataSourceMessages in the afm spec)
• result.metadata is accessible as a raw dict at runtime because _check_return_type=False is used in all API calls
• The cassette for test_execution_result_limit_break will be recorded against a staging server configured with a row-count limit low enough to be triggered by the demo workspace execution

Risks (2)

• result.metadata.get('limitBreaks') uses type: ignore because models.ExecutionResultMetadata stub lacks get(); will be cleanable after api-client regeneration
• Integration test cassette requires a staging server with limit configuration — if not available, the len(raw_breaks) > 0 assertion will fail and the cassette must be recorded in a specifically configured environment

Layers touched (3)

• entity_model — New ExecutionResultLimitBreak attrs class
  • packages/gooddata-sdk/src/gooddata_sdk/compute/model/limit_break.py
• public_api — Re-exported ExecutionResultLimitBreak
  • packages/gooddata-sdk/src/gooddata_sdk/__init__.py
• tests — Unit tests + integration test
  • packages/gooddata-sdk/tests/compute/test_execution_result_limit_break.py
  • packages/gooddata-sdk/tests/compute/test_execution_limit_break_integration.py

OpenAPI diff

--- a/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

[tychtjan]

Analyze why the pipeline is failing at the unit test level ? It seems like the test you implemented doesn't work correctly. Analyse please