kindred/silo-client
1
1
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add runner-facing API methods (heartbeat, claim, progress, complete, fail, log) #11

New Issue
Open
opened 2026-02-16 15:56:02 +00:00 by forbes · 0 comments
forbes commented 2026-02-16 15:56:02 +00:00
Owner
Copy Link

Summary

The WORKERS.md spec defines 7 runner-facing endpoints that allow silorunner processes to interact with the job queue. None are implemented in the client.

Missing Methods

Server Endpoint Proposed Method
POST /api/runner/heartbeat runner_heartbeat()
POST /api/runner/claim runner_claim_job()
PUT /api/runner/jobs/{jobID}/progress runner_report_progress(job_id, progress, message)
POST /api/runner/jobs/{jobID}/complete runner_complete_job(job_id, result)
POST /api/runner/jobs/{jobID}/fail runner_fail_job(job_id, error_message)
POST /api/runner/jobs/{jobID}/log runner_append_log(job_id, level, message, metadata)
PUT /api/runner/jobs/{jobID}/dag runner_sync_dag(job_id, nodes, edges)

Design Consideration

Runner endpoints use a different auth mechanism -- Authorization: Bearer silo_runner_<token> validated by a dedicated RequireRunnerAuth middleware. The client may need a way to configure runner token auth separately from user token auth, or a separate SiloRunnerClient subclass/mode.

Options:

  1. Add a runner_token parameter to SiloSettings and a _runner_auth_headers() method
  2. Create a SiloRunnerClient that extends SiloClient with runner-specific methods
  3. Use the same SiloClient but allow passing a runner token at construction time

References

  • WORKERS.md Section 5 (Runners)
  • WORKERS.md Section 8.4 (Runner-Facing Endpoints)
## Summary The WORKERS.md spec defines 7 runner-facing endpoints that allow `silorunner` processes to interact with the job queue. None are implemented in the client. ## Missing Methods | Server Endpoint | Proposed Method | |---|---| | `POST /api/runner/heartbeat` | `runner_heartbeat()` | | `POST /api/runner/claim` | `runner_claim_job()` | | `PUT /api/runner/jobs/{jobID}/progress` | `runner_report_progress(job_id, progress, message)` | | `POST /api/runner/jobs/{jobID}/complete` | `runner_complete_job(job_id, result)` | | `POST /api/runner/jobs/{jobID}/fail` | `runner_fail_job(job_id, error_message)` | | `POST /api/runner/jobs/{jobID}/log` | `runner_append_log(job_id, level, message, metadata)` | | `PUT /api/runner/jobs/{jobID}/dag` | `runner_sync_dag(job_id, nodes, edges)` | ## Design Consideration Runner endpoints use a different auth mechanism -- `Authorization: Bearer silo_runner_<token>` validated by a dedicated `RequireRunnerAuth` middleware. The client may need a way to configure runner token auth separately from user token auth, or a separate `SiloRunnerClient` subclass/mode. Options: 1. Add a `runner_token` parameter to `SiloSettings` and a `_runner_auth_headers()` method 2. Create a `SiloRunnerClient` that extends `SiloClient` with runner-specific methods 3. Use the same `SiloClient` but allow passing a runner token at construction time ## References - WORKERS.md Section 5 (Runners) - WORKERS.md Section 8.4 (Runner-Facing Endpoints)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
forbes
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kindred/silo-client#11
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?