Persist publish jobs (publish_jobs table) like bDS2 #86

New Issue

hugo · 2026-07-20T19:44:01Z

hugo commented

2026-07-20 19:44:01 +00:00

Source: Audit section 2.16.

bDS2: has a publish_jobs DB table (../bDS2/priv/repo/migrations/20260424100817_add_backend_spec_compliance_persistence.exs ~line 5, indexed by project_id) with a get_job/1 API (../bDS2/lib/bds/publishing.ex:77) — publish jobs survive as queryable records.

Current behaviour (RuDS): crates/bds-core/src/engine/publishing.rs models PublishJob in memory only; nothing is persisted. specs/publishing.allium models the PublishJob entity but is silent on persistence, and specs/schema.allium omits the table (see companion spec-update issue).

Task: Decide with the maintainer whether job persistence/history is wanted in RuDS. If yes: create the table with a proper Diesel migration (use the migration tooling, sqlite semantics, no hand-hacked SQL per AGENTS.md), matching bDS2's columns; write job rows through the upload lifecycle (pending→running→completed/failed with error); expose history where the UI shows publish state (functionality must be tied to UI). If no: close this and note the intentional divergence in specs/publishing.allium.

Acceptance: Either persisted jobs matching bDS2's shape + migration + UI surfacing, or documented decision in the spec.

**Source:** Audit section 2.16. **bDS2:** has a `publish_jobs` DB table (`../bDS2/priv/repo/migrations/20260424100817_add_backend_spec_compliance_persistence.exs` ~line 5, indexed by project_id) with a `get_job/1` API (`../bDS2/lib/bds/publishing.ex:77`) — publish jobs survive as queryable records. **Current behaviour (RuDS):** `crates/bds-core/src/engine/publishing.rs` models PublishJob in memory only; nothing is persisted. `specs/publishing.allium` models the PublishJob entity but is silent on persistence, and `specs/schema.allium` omits the table (see companion spec-update issue). **Task:** Decide with the maintainer whether job persistence/history is wanted in RuDS. If yes: create the table with a proper Diesel migration (use the migration tooling, sqlite semantics, no hand-hacked SQL per AGENTS.md), matching bDS2's columns; write job rows through the upload lifecycle (pending→running→completed/failed with error); expose history where the UI shows publish state (functionality must be tied to UI). If no: close this and note the intentional divergence in specs/publishing.allium. **Acceptance:** Either persisted jobs matching bDS2's shape + migration + UI surfacing, or documented decision in the spec.

hugo added the enhancement label 2026-07-20 19:44:01 +00:00

hugo commented

2026-07-20 19:59:36 +00:00

Decision by maintainer: persisted jobs bring no value, follow the spec and current implementation and do not implement that feature, just clarify the spec that no persistence of jobs is needed.

hugo added the wontfix label 2026-07-20 20:05:49 +00:00

hugo commented

2026-07-20 20:05:57 +00:00

decided this is not relevant.

hugo closed this issue

2026-07-20 20:05:57 +00:00

hugo referenced this issue

2026-07-22 17:18:15 +00:00

Update schema.allium: mcp_proposals, chat surface state, publish_jobs #94

Sign in to join this conversation.