feat(solver): Phase 3b — server endpoints and solver_results table #156

Closed
opened 2026-02-20 02:01:45 +00:00 by forbes · 0 comments
Owner

Phase 3b: Server Endpoints

Add the solver module to the Silo server. This builds on the existing job queue infrastructure (015_jobs_runners.sql, internal/db/jobs.go, internal/api/job_handlers.go, internal/api/runner_handlers.go).

See docs/SOLVER.md — Phase 3b

Files to create

  • internal/modules/solver/solver.go — Module registration and config
  • internal/modules/solver/handlers.go — REST endpoint handlers (solver-specific convenience layer over existing /api/jobs)
  • migrations/021_solver_results.sql — Database migration for result caching table

Endpoints

Method Path Description
POST /api/solver/jobs Submit solve job (validates SolveContext, creates job via existing queue)
GET /api/solver/jobs/{id} Get solver job status + result
GET /api/solver/jobs List solver jobs (filtered)
POST /api/solver/jobs/{id}/cancel Cancel pending/claimed job
GET /api/solver/solvers Get solver registry from runner metadata

Database

solver_results table for quick lookup by item/revision:

  • UNIQUE(item_id, revision_number, operation) — one result per operation per revision
  • Upserted on job completion from jobs.result JSONB

Config

modules:
  solver:
    enabled: true
    default_solver: "ondsel"
    max_context_size_mb: 10
    default_timeout: 300
    auto_diagnose_on_commit: true

Dependencies

  • Requires jobs module enabled
  • Phase 3a (JSON serialization) for real payloads, but can be built and tested with mock SolveContext JSON
  • All solver endpoints gated behind RequireModule("solver")
  • SSE uses existing job.* event prefix — no new event types needed
## Phase 3b: Server Endpoints Add the solver module to the Silo server. This builds on the existing job queue infrastructure (`015_jobs_runners.sql`, `internal/db/jobs.go`, `internal/api/job_handlers.go`, `internal/api/runner_handlers.go`). See [docs/SOLVER.md — Phase 3b](../docs/SOLVER.md#phase-3b-server-endpoints) ### Files to create - `internal/modules/solver/solver.go` — Module registration and config - `internal/modules/solver/handlers.go` — REST endpoint handlers (solver-specific convenience layer over existing `/api/jobs`) - `migrations/021_solver_results.sql` — Database migration for result caching table ### Endpoints | Method | Path | Description | |--------|------|-------------| | POST | `/api/solver/jobs` | Submit solve job (validates SolveContext, creates job via existing queue) | | GET | `/api/solver/jobs/{id}` | Get solver job status + result | | GET | `/api/solver/jobs` | List solver jobs (filtered) | | POST | `/api/solver/jobs/{id}/cancel` | Cancel pending/claimed job | | GET | `/api/solver/solvers` | Get solver registry from runner metadata | ### Database `solver_results` table for quick lookup by item/revision: - `UNIQUE(item_id, revision_number, operation)` — one result per operation per revision - Upserted on job completion from `jobs.result` JSONB ### Config ```yaml modules: solver: enabled: true default_solver: "ondsel" max_context_size_mb: 10 default_timeout: 300 auto_diagnose_on_commit: true ``` ### Dependencies - Requires `jobs` module enabled - Phase 3a (JSON serialization) for real payloads, but can be built and tested with mock SolveContext JSON - All solver endpoints gated behind `RequireModule("solver")` - SSE uses existing `job.*` event prefix — no new event types needed
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/silo#156