Skip to content

client SDK: add approvals namespace; remove dead workflow surface (ADR-0019) #1515

Description

@xuyushun441-sys

Summary

The @objectstack/client SDK is out of sync with the server REST surface around approvals/workflow:

  1. Missing: there is no client.approvals namespace, even though the server exposes the canonical approval-decision API. This is the only path that resumes a suspended flow run (ADR-0019), so without a typed method every consumer hand-rolls fetch, or worse, bypasses it by data.update-ing the request status (which mirrors the status but does not resume the flow).
  2. Dead:client.workflow.* and the workflow route/contract are leftovers from the workflow engine that was removed (Workflow Rules removed in refactor(automation): remove Workflow Rules; reclaim workflow for state machines #1398; approval collapsed into Flow in ADR-0019). Nothing implements /api/v1/workflow anywhere in the monorepo — these methods can never succeed.

Found while building the mobile app's approvals UI: client.workflow.approve silently no-ops and there's no typed approvals call, so we had to data.update the status (semantically wrong — the blocked flow run is never resumed).

Evidence

Server HAS the approvals APIpackages/rest/src/rest-server.tsregisterApprovalsEndpoints() (always mounted; service via ctx.getService('approvals')):

  • GET /api/v1/approvals/requests (filters: status, object, recordId, approverId, submitterId)
  • GET /api/v1/approvals/requests/:id
  • POST /api/v1/approvals/requests/:id/approve -> svc.decide() -> finalizes the request and resumes the owning flow run
  • POST /api/v1/approvals/requests/:id/reject
  • GET /api/v1/approvals/requests/:id/actions (audit trail)

Client LACKS itpackages/client/src/index.ts: no approvals namespace and no approvals key in the route map (getRoute, ~line 3277).

workflow is dead — no /api/v1/workflow route is registered anywhere; no service-workflow / plugin-workflow package exists. Only leftovers remain:

  • packages/client/src/index.ts:2464workflow = { getConfig, getState, transition, approve, reject }
  • packages/client/src/index.ts:3288 — route map workflow: '/api/v1/workflow'
  • packages/spec/src/contracts/workflow-service.tsIWorkflowService contract (+ Workflow* types), unimplemented/unregistered
  • packages/spec/src/system/core-services.zod.ts:42,84'workflow' CoreServiceName (optional), surfaces as workflow: { status: 'unavailable' } in discovery

Per ADR-0019 ("Collapse Approval into Flow"): "Workflow Rules were already removed in #1398, and workflow was reclaimed for state machines." — but no state-machine workflow service was ever shipped, so the surface is dangling.

Proposed changes

Add client.approvals (mirror the existing automation namespace style):

approvals={list: (filters?)=>GET/api/v1/approvals/requests?,get: (id)=>GET/api/v1/approvals/requests/:id,approve: (id,{comment?,actorId? })=>POST/api/v1/approvals/requests/:id/approve,reject: (id,{comment?,actorId? })=>POST/api/v1/approvals/requests/:id/reject,actions: (id)=>GET/api/v1/approvals/requests/:id/actions,}
  • add approvals: '/api/v1/approvals' to the route map.

Remove the dead workflow surface:

  • delete the workflow namespace + route-map entry in packages/client/src/index.ts
  • delete packages/spec/src/contracts/workflow-service.ts (IWorkflowService, Workflow* types) and its test
  • drop 'workflow' from CoreServiceName (core-services.zod.ts) and any discovery default that advertises it

Note: object state machines now live as Flow nodes / field-level, so transition/getState/getConfig have no replacement — remove, don't re-point.

Acceptance criteria

  • client.approvals.{list,get,approve,reject,actions} exist and hit /api/v1/approvals/requests…
  • No workflow references remain in @objectstack/client (namespace + route map)
  • IWorkflowService / Workflow* types and the 'workflow' CoreServiceName removed (or explicitly kept with a deprecation note if state-machine work is still planned)
  • discovery no longer advertises a workflow service
  • spec + client typecheck/test green

Secondary (separate issue?)

reports (/api/v1/reports…, 8 routes) and sharing/sharingRules (/api/v1/sharing/rules…) also have server routes but no client namespace.


Filed from the mobile app, which will switch its approvals decision to client.approvals.approve once this lands (currently using a data.update workaround that doesn't resume the flow).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions