Behaviour for pluggable task storage backends.

ConduitMCP uses tasks to model long-running MCP operations (the tasks/* JSON-RPC routes in the 2025-11-25 spec). The default implementation, ConduitMcp.Tasks.EtsStore, keeps tasks in-memory and is ideal for single-node, ephemeral workloads. To survive restarts, distribute across nodes, or back tasks with a job queue, implement this behaviour and configure it as the application's task store:

config :conduit_mcp, :tasks_store, MyApp.MyTasksStore

The standard tasks/get, tasks/cancel, tasks/result, and tasks/list handler routes dispatch through ConduitMcp.Tasks, which forwards every storage call to the configured store. No handler changes are required.

Implementing a Custom Store

A custom store must persist whatever map shape the worker writes (the framework adds "task_id", "status", and "created_at" on create/2 and never reads other keys itself, so any extra fields are preserved verbatim).

Example: Postgres-backed Store

defmodule MyApp.PostgresTaskStore do
  @behaviour ConduitMcp.Tasks.Store

  alias MyApp.{Repo, McpTask}

  @impl true
  def create(task_id, metadata) do
    task = Map.merge(metadata, %{"task_id" => task_id, "status" => "working",
                                 "created_at" => System.system_time(:millisecond)})
    %McpTask{}
    |> McpTask.changeset(task)
    |> Repo.insert()
    |> case do
      {:ok, row} -> {:ok, McpTask.to_map(row)}
      err        -> err
    end
  end

  @impl true
  def get(task_id) do
    case Repo.get(McpTask, task_id) do
      nil -> {:error, :not_found}
      row -> {:ok, McpTask.to_map(row)}
    end
  end

  # ...update/2, cancel/1, delete/1, list/1, cleanup/1
end

See examples/oban_tasks_server/ for an Oban + SQLite implementation and examples/oban_task_store.ex for a Postgres-flavored reference.

Configuration

# Default — in-memory ETS, zero config
# (equivalent to omitting the key)
config :conduit_mcp, :tasks_store, ConduitMcp.Tasks.EtsStore

# Custom store
config :conduit_mcp, :tasks_store, MyApp.MyTasksStore