Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Praashh/buildml/llms.txt

Use this file to discover all available pages before exploring further.

The problemRouter exposes two public query procedures for listing and retrieving individual AI/ML coding problems. Every Problem record carries a full problem statement, Python starter code (templateCode), the Python test script used by the executor (testCode), and a difficulty tier. No authentication is required to read problem data.

​
problem.getAll

Returns every problem in the database, ordered by creation date (newest first). Each result includes the parent problemSet object so you can display set metadata alongside problems in listing views. Type: query — Auth: public Input: none 
import { api } from '~/trpc/server';

const problems = await api.problem.getAll();
// problems[0].problemSet => parent ProblemSet record

​
Response

An array of Problem objects ordered by createdAt descending. Each element has the following shape:
​
id
string
required
Unique CUID identifier for the problem.
​
title
string
required
Display title of the problem (e.g., "Implement Sigmoid").
​
slug
string
required
URL-safe unique identifier used in routing (e.g., "implement-sigmoid").
​
description
string
required
Full problem statement written in Markdown. Stored as @db.Text.
​
difficulty
string
required
Difficulty tier: "Easy", "Medium", or "Hard".
​
templateCode
string
required
Python starter code presented to the user in the code editor (solution.py). Stored as @db.Text.
​
testCode
string
required
Python verification script run by the FastAPI executor against the user’s submission (tests.py). Stored as @db.Text.
​
order
number
required
Position of this problem within its parent set. Defaults to 0.
​
problemSetId
string | null
Foreign key of the parent ProblemSet. May be null for standalone problems.
​
problemSet
ProblemSet | null
The parent problem set record, eagerly loaded via Prisma include.
​
createdAt
DateTime
required
ISO 8601 timestamp of when the problem was created.
​
updatedAt
DateTime
required
ISO 8601 timestamp of the last update to the problem record.

​
problem.getBySlug

Fetches a single problem by its unique slug, including the parent problemSet. Returns null if no matching record is found. Use this procedure on the problem detail / editor page to load everything the UI needs in one round-trip. Type: query — Auth: public Input: { slug: string }
​
slug
string
required
The URL-safe slug of the problem to fetch (e.g., "implement-sigmoid"). Validated by Zod as a non-empty string.
import { api } from '~/trpc/server';
import { notFound } from 'next/navigation';

const problem = await api.problem.getBySlug({ slug: 'implement-sigmoid' });
if (!problem) notFound();

// problem.templateCode => Python starter to show in the editor
// problem.testCode     => Python test script (executor-internal)

​
Response

A single Problem object — or null when no record matches the given slug.
​
id
string
required
Unique CUID identifier for the problem.
​
title
string
required
Display title (e.g., "Implement Sigmoid").
​
slug
string
required
URL-safe unique identifier.
​
description
string
required
Full Markdown problem statement shown to the user in the description panel.
​
difficulty
string
required
Difficulty tier: "Easy", "Medium", or "Hard".
​
templateCode
string
required
Python starter code pre-loaded into the editor when the user opens the problem for the first time.
​
testCode
string
required
Python test script used internally by the FastAPI executor to validate the user’s solution. Not displayed in the UI.
​
order
number
required
Integer position within the parent problem set. Defaults to 0.
​
problemSetId
string | null
Foreign key of the parent ProblemSet. May be null for standalone problems.
​
problemSet
ProblemSet | null
The parent problem set, eagerly loaded.
​
createdAt
DateTime
required
ISO 8601 creation timestamp.
​
updatedAt
DateTime
required
ISO 8601 last-updated timestamp.
testCode is fetched alongside the problem record but should not be exposed to users in the browser — avoid rendering it in client components to prevent cheating. Prefer loading this field only in Server Components or API routes that interact with the executor.

Build docs developers (and LLMs) love

Get started for freeTalk to us