A minimal asynchronous task service built with FastAPI, designed to simulate how backend systems handle background work like sending notifications, generating reports, and writing files — after returning the response to the client. It showcases FastAPI’s BackgroundTasks, custom task tracking, retry logic, and simulated async file generation using Python’s standard library.

This API allows you to trigger background jobs, track task progress, and optionally retry failed tasks. All tasks are simulated and tracked in-memory using a task registry.

Description: Triggers a background task to simulate sending an email notification.

Request Body:

{
  "email": "johndoe@example.com",
  "message": "Your submission was received."
}

Response: 202 Accepted

{
  "task_id": "uuid",
  "status": "started"
}

Description: Triggers a background task to simulate generating a report.

Request Body:

{
  "name": "Sales Report",
  "details": {
    "month": "June",
    "region": "Asia"
  }
}

Response: 202 Accepted

{
  "task_id": "uuid",
  "status": "started"
}

Description: Triggers an async task to generate and save a .json file from provided content.

Request Body:

{
  "content": {
    "user": "johndoe",
    "activity": "export"
  }
}

Response: 202 Accepted

{
  "task_id": "uuid",
  "status": "started"
}

Description: Returns the status of a task, including result or error message if applicable.

Response: 200 OK

{
  "id": "uuid",
  "type": "report",
  "status": "success",
  "result": {
    "message": "Report generated"
  },
  "error": null,
  "timestamp": "2025-06-26T..."
}

Error:

• 404 Not Found if task ID does not exist

Description: Manually re-triggers a previously failed task.

Response: 200 OK

{
  "task_id": "uuid",
  "status": "retried"
}

Error:

• 400 Bad Request if task is not in a "failed" state
• 404 Not Found if task ID is invalid or missing

Tasks are stored in an in-memory task_store dictionary. Each task contains:

• All background functions are wrapped in try/except blocks
• On failure, the error is logged in the task metadata
• Failed tasks can be manually retried via /retry-task/{task_id}
• Retry count is tracked in the task_store

• No external queue like Celery or Redis is used — everything is in-memory for simulation.
• File generation is synchronous but triggered through BackgroundTasks for realism.
• Task IDs are generated via uuid4() and used to reference status.