Conversation
📝 WalkthroughWalkthroughThe pull request introduces a comprehensive TypeSpec API specification for managing workout templates and planned workouts, with support for various sport types, intensity targets, and completion conditions. An import statement is added to the main data models file to include the new PlannedWorkouts module in the data model ecosystem. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@data_models/main.tsp`:
- Line 14: PlannedWorkouts.tsp is using OpenAPI/REST decorators
(`@service/`@server and imports `@typespec/http`, `@typespec/rest`,
`@typespec/openapi3`) but the build only emits JSON Schema; either enable the
OpenAPI emitter in tspconfig.yaml or convert PlannedWorkouts.tsp to the
project's JSON Schema style. To fix: open tspconfig.yaml and add the OpenAPI
emitter configuration (enable `@typespec/openapi3` output) so the `@service/`@server
decorators in PlannedWorkouts.tsp are processed, or refactor the
PlannedWorkouts.tsp file to remove
`@typespec/http/`@typespec/rest/@typespec/openapi3 usage and model the API types
using the same JSON Schema-oriented patterns used by other data model files
(keeping type names and endpoints equivalent). Ensure references to
PlannedWorkouts.tsp, `@service`, `@server`, and tspconfig.yaml are updated
accordingly.
🧹 Nitpick comments (4)
data_models/specs/data_models/PlannedWorkouts.tsp (4)
88-91: Consider renamingifto avoid reserved keyword conflicts.The
ifenum value represents the TrainingPeaks Intensity Factor metric. While TypeSpec allows backtick escaping, this may cause code generation issues in languages whereifis reserved (TypeScript, Python, Java, etc.).Consider using
intensity_factorinstead:// TrainingPeaks-style targets tss: "tss", - `if`: "if", + intensity_factor: "if",
315-316: Consider adding format validation for date fields.
created_dateandupdated_datelack@patternvalidation while other date fields in this spec (e.g.,planned_date) use@pattern("^\\d{4}-\\d{2}-\\d{2}$"). If these fields follow a specific format (ISO 8601 datetime or YYYY-MM-DD), consider adding validation for consistency.- created_date?: string; - updated_date?: string; + /** ISO 8601 datetime when the planned workout was created */ + created_date?: utcDateTime; + + /** ISO 8601 datetime when the planned workout was last updated */ + updated_date?: utcDateTime;
380-391: Add@patternvalidation to date query parameters for consistency.The
start_dateandend_datequery parameters lack the@patternvalidation used elsewhere in this spec (e.g.,planned_datein request models). The doc comment indicates expected formatYYYY-MM-DD.Suggested fix
op listPlannedWorkouts( ...TerraHeaders, `@query` user_id: string, - `@query` start_date?: string, - `@query` end_date?: string + `@query` `@pattern`("^\\d{4}-\\d{2}-\\d{2}$") start_date?: string, + `@query` `@pattern`("^\\d{4}-\\d{2}-\\d{2}$") end_date?: string ): ListPlannedWorkoutsResponse | {
334-346: Consider adding 401 Unauthorized response for authentication failures.All endpoints require authentication via
TerraHeaders(dev-id, x-api-key), but none define a 401 response for invalid or missing credentials. This would improve API completeness and client error handling.Example for createWorkoutTemplate
op createWorkoutTemplate( ...TerraHeaders, `@body` body: CreateWorkoutTemplateRequest ): CreateWorkoutTemplateResponse | { + `@statusCode` statusCode: 401; + `@body` error: { detail: string }; + } | { `@statusCode` statusCode: 400; `@body` error: { detail: string }; } | {This pattern should be applied to all endpoints in both namespaces.
| import "./specs/data_models/Athlete.tsp"; | ||
| import "./specs/data_models/Body.tsp"; | ||
| import "./specs/data_models/Events.tsp"; | ||
| import "./specs/data_models/PlannedWorkouts.tsp"; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's check if the file exists and understand the repository structure
echo "=== Repository structure ==="
ls -la data_models/
echo ""
echo "=== Main file content ==="
cat -n data_models/main.tsp
echo ""
echo "=== Checking PlannedWorkouts.tsp for `@service/`@server decorators ==="
if [ -f "data_models/specs/data_models/PlannedWorkouts.tsp" ]; then
echo "--- PlannedWorkouts.tsp (first 30 lines) ---"
head -30 "data_models/specs/data_models/PlannedWorkouts.tsp"
else
echo "PlannedWorkouts.tsp not found"
fi
echo ""
echo "=== Checking decorators in imported files ==="
for f in enums common Samples TerraUser Activity Daily Sleep Nutrition Menstruation Athlete Body Events; do
file="data_models/specs/data_models/${f}.tsp"
if [ -f "$file" ]; then
echo "--- $file ---"
head -30 "$file" | grep -E "@(service|server|jsonSchema)" || echo "(no service/server/jsonSchema decorators in first 30 lines)"
else
echo "--- $file (NOT FOUND) ---"
fi
doneRepository: tryterra/openapi
Length of output: 3968
🏁 Script executed:
#!/bin/bash
echo "=== tspconfig.yaml content ==="
cat -n tspconfig.yaml
echo ""
echo "=== package.json scripts ==="
cat package.json | grep -A 10 '"scripts"'
echo ""
echo "=== Check src directory structure ==="
ls -la src/ 2>/dev/null || echo "src/ not found"
echo ""
echo "=== Check specs directory structure ==="
find specs -type f -name "*.tsp" | head -20Repository: tryterra/openapi
Length of output: 365
🏁 Script executed:
#!/bin/bash
echo "=== Current directory ==="
pwd
echo ""
echo "=== tspconfig.yaml content ==="
if [ -f "data_models/tspconfig.yaml" ]; then
cat -n "data_models/tspconfig.yaml"
elif [ -f "tspconfig.yaml" ]; then
cat -n tspconfig.yaml
fi
echo ""
echo "=== package.json scripts section ==="
if [ -f "data_models/package.json" ]; then
cat "data_models/package.json" | jq '.scripts' 2>/dev/null || grep -A 5 '"scripts"' "data_models/package.json"
elif [ -f "package.json" ]; then
cat package.json | jq '.scripts' 2>/dev/null || grep -A 5 '"scripts"' package.json
fi
echo ""
echo "=== Check if PlannedWorkouts appears in any config files ==="
find . -type f \( -name "*.json" -o -name "*.yaml" -o -name "*.yml" \) -exec grep -l "PlannedWorkouts" {} \; 2>/dev/nullRepository: tryterra/openapi
Length of output: 658
PlannedWorkouts.tsp uses OpenAPI/REST decorators but the build pipeline is not configured to emit OpenAPI output.
PlannedWorkouts.tsp imports @typespec/http, @typespec/rest, and @typespec/openapi3, and applies @service/@server decorators for OpenAPI generation. However, tspconfig.yaml is configured to emit only @typespec/json-schema output, not OpenAPI. The @service/@server decorators in PlannedWorkouts will not be processed or emitted by the build pipeline. Either add the OpenAPI emitter configuration to tspconfig.yaml or refactor PlannedWorkouts.tsp to use the JSON Schema paradigm consistent with other data models.
🤖 Prompt for AI Agents
In `@data_models/main.tsp` at line 14, PlannedWorkouts.tsp is using OpenAPI/REST
decorators (`@service/`@server and imports `@typespec/http`, `@typespec/rest`,
`@typespec/openapi3`) but the build only emits JSON Schema; either enable the
OpenAPI emitter in tspconfig.yaml or convert PlannedWorkouts.tsp to the
project's JSON Schema style. To fix: open tspconfig.yaml and add the OpenAPI
emitter configuration (enable `@typespec/openapi3` output) so the `@service/`@server
decorators in PlannedWorkouts.tsp are processed, or refactor the
PlannedWorkouts.tsp file to remove
`@typespec/http/`@typespec/rest/@typespec/openapi3 usage and model the API types
using the same JSON Schema-oriented patterns used by other data model files
(keeping type names and endpoints equivalent). Ensure references to
PlannedWorkouts.tsp, `@service`, `@server`, and tspconfig.yaml are updated
accordingly.
Summary by CodeRabbit