Skip to content

Define Proper Pydantic Schema for `result` Field in Job Response

Description

Currently, the result field in the job response model is not defined using a proper Pydantic schema. It is being handled as a generic structure (e.g., Dict[str, Any]), which allows arbitrary data without validation.

Example of current response:

{
  "job_id": "string",
  "status": "pending",
  "language": "string",
  "created_at": "string",
  "result": {
    "additionalProp1": {}
  },
  "error": "string"
}

The "additionalProp1" key indicates that the structure of result is undefined and lacks a strict schema.

Problem

  • No validation for result field
  • Unclear structure for API consumers
  • Weak type safety
  • Poor API documentation (Swagger/OpenAPI)

Objective

Introduce a proper Pydantic schema for the result field to ensure structured, validated, and well-documented API responses.

Expected Changes

  • Create a new Pydantic model (e.g., ResultSchema)
  • Replace Dict[str, Any] with ResultSchema in the response model
  • Keep result as an optional field
  • Ensure compatibility with existing endpoints
  • Update API documentation automatically via FastAPI

Acceptance Criteria

  • result field uses a defined Pydantic model
  • API rejects invalid result formats
  • Swagger docs show structured schema for result
  • Existing functionality remains unaffected

Impact

  • Improved data validation
  • Better API clarity and maintainability
  • Enhanced developer experience