Debugging

Jadpo code is written mainly by coding agents and read by people, so two jobs matter most. When something goes wrong, you or your agent need to get from the symptom to the .jadpo line and the reason, without reading the code Jadpo generates. And when an agent hands over a large change, you need to see what it does to your app, such as who can now read which data, before you read it line by line. This page covers both: where errors point, how to see what a request did and why, and how to review a change.

The command line, the developer console and the agent tools (MCP) all show the same evidence. The compiler and the runtime record that evidence, and each view only displays it. If the console shows why a caller was refused, that's because the compiler and the runtime recorded the reason, not because the console worked it out.

Most of this isn't built yet; What is built says which parts are.

A request in jadpo dev

jadpo dev runs your app and prints one line for each request, with its request id, its status and how long it took, so it is where most debugging starts. Here is a small app with one route, which stores nothing and which anyone may call:

domains/todos/routes/todos.jadpo:

use todos/types { NewTodo, TodoView }use todos/actions { add_todo }/// The todo list.routes Todos {    prefix: /todos    /// Adds a todo.    POST / {        authentication: RouteAuthentication.none        input: NewTodo        output: TodoView        run: add_todo(input)    }}

domains/todos/types/new_todo.jadpo:

/// What a caller sends to add a todo.type NewTodo = Input {    title: Text}

domains/todos/types/todo_view.jadpo:

/// A todo, as the app sends it back.type TodoView = Output {    title: Text    done: Bool}

domains/todos/actions/add_todo.jadpo:

use todos/types { NewTodo, TodoView }/// Builds the todo and sends it back. It stores nothing.action add_todo(input: NewTodo) -> TodoView {    return TodoView {        title: input.title        done: false    }}

policy.jadpo:

use todospolicy {    actions: {        todos.add_todo: [Access.public]    }}

RouteAuthentication, Access, Text and Bool are built into Jadpo, and every other name is declared here. Run jadpo api update once, then jadpo dev, and send it two requests:

curl -X POST http://localhost:3000/todos \  -H 'content-type: application/json' -d '{"title": "Buy milk"}'curl -X POST http://localhost:3000/todos \  -H 'content-type: application/json' -d '{"title": 5}'

$ jadpo devjadpo dev, started 02:47:52listening on http://localhost:3000    routes  2 routesserving: saves reload, press ctrl-c to quitreq_4035  POST /todos                        200   6 ms   127.0.0.1req_beb8  POST /todos                        422 invalid_input   0 ms   127.0.0.1

The second title isn't text, so the app refused it with a 422 and said why. Its line shows the start of the request's id, which the caller also has in the x-request-id header and an error's request_id, so a report from a caller leads to the line.

What is built says which of this works today.