HR-based end conditions on recovery steps cause API 500 DataIntegrityViolationException

[r-3ll]

Describe the bug

Using a heart rate-based end condition on a recovery step causes a server-side 500 error when uploading a workout via the MCP.

Steps to reproduce

Build a threshold workout with a recovery step using an HR-based end condition:

{
  "type": "ExecutableStepDTO",
  "stepType": { "stepTypeId": 4, "stepTypeKey": "recovery" },
  "endCondition": {
    "conditionTypeId": 6,
    "conditionTypeKey": "heart.rate"
  },
  "endConditionValue": 145
}

Upload via upload_workout or upload_workouts.

Expected behaviour

Workout uploads successfully with an HR-triggered recovery end condition.

Actual behaviour

API Error 500 - {'clientMessage': 'Reference Error ID in error logs for further information', 'errorId': '666905c5-e39a-410f-97eb-7081a5dcc186', 'error': 'DataIntegrityViolationException'}

Earlier in the same session, using conditionTypeId: 4 with conditionTypeKey: "heart.rate" returned a different error:

conditionTypeKey 'heart.rate' requires conditionTypeId 6, got 4 (calories)

So conditionTypeId 4 is rejected client-side, and conditionTypeId 6 is rejected server-side. Neither works.

Workaround

Use lap.button (conditionTypeId 1, conditionTypeKey "lap.button") for recovery steps where HR-based end conditions are desired. The user presses LAP manually when the target HR is reached.

Environment

• Garmin MCP via Claude (Anthropic)
• Workout type: running threshold session

[Taxuspt]

Thanks for the detailed bug report. After investigating, this appears to be a Garmin API server-side limitation rather than a bug in the MCP code.

What we found:

• conditionTypeId: 4 = calories (not heart rate) — correctly rejected client-side
• conditionTypeId: 6 = heart rate — accepted client-side, but Garmin's server returns DataIntegrityViolationException

The server-side rejection with DataIntegrityViolationException suggests Garmin's workout API doesn't support HR-based end conditions for recovery step types at their backend level — the API design may assume HR end conditions require additional fields not documented in the public API surface.

Recommended workaround (as you noted): Use lap.button (conditionTypeId: 1) for recovery steps where you want the step to end when a target HR is reached, and press LAP manually.

{
  "stepType": { "stepTypeId": 4, "stepTypeKey": "recovery" },
  "endCondition": {
    "conditionTypeId": 1,
    "conditionTypeKey": "lap.button"
  }
}

If you find a working HR end condition payload structure (e.g. through Garmin Connect's own web app traffic), please share it here and we can add it to the workout tool documentation.