Epic: Port /api/schema resource from Orkes for input/output schema management

[nthmost-orkes]

Overview

Port the /api/schema REST resource (and its supporting service + persistence) from Orkes Conductor to OSS, so that input/output schemas can be defined once, stored centrally, and referenced from task definitions (taskDef.inputSchema / outputSchema). The UI already calls /api/schema for the Simple Task input/output schema picker, but the endpoint does not exist in OSS — today the picker has to be hidden behind a feature flag.

Problem Statement

SchemaDef exists in OSS (conductor/common/src/main/java/com/netflix/conductor/common/metadata/SchemaDef.java) and DeciderService already consumes taskDef.inputSchema / outputSchema for validation. What's missing is the management surface: a REST resource, a service, and persistence so users can CRUD schemas and the UI can list them in pickers.

Orkes ships exactly this surface in io.orkes.conductor.server.rest.SchemaResource + io.orkes.conductor.integration.service.SchemaService. UI, Java SDK, and Python SDK all hit /api/schema with specific payload shapes and JSON field names. Diverging on path or shape would force every client to branch on backend type.

Parity Strategy

Mirror the Orkes layout exactly, swapping only the namespace (io.orkes.conductor.* → org.conductoross.conductor.*).

Orkes (source of truth)	OSS port
io.orkes.conductor.server.rest.SchemaResource	org.conductoross.conductor.rest.SchemaResource
io.orkes.conductor.integration.service.SchemaService	org.conductoross.conductor.service.SchemaService
@RequestMapping("/api/schema")	identical
Methods: save, getSchemaByNameWithLatestVersion, getSchemaByNameAndVersion, getAllSchemas, deleteSchemaByName, deleteSchemaByNameAndVersion	identical names + signatures
Query params: ?short=, ?newVersion=	identical

Orkes vs OSS: What Changes

Component	Orkes	OSS	Change
REST path + payloads	/api/schema + SchemaDef	Same	Keep
SchemaDef model	com.netflix.conductor.common.metadata.SchemaDef	Same (already in OSS)	Keep
DAO interface	SchemaDAO (org-scoped)	Same signatures, OSS passes "default" orgId	Simplify
OrkesAuthentication / Permissions.METADATA_MANAGEMENT	Required guards	Removed	Drop enterprise auth
TagsService / AutomaticTagService	Auto-tags on save/delete	Removed	Drop enterprise tagging
Persistence	Orkes-internal	Postgres + MySQL implementations modeled on scheduler/	Add

Convergence Requirement

The DAO interface and JSON payloads must match Orkes exactly so Orkes can adopt the OSS module with only the orgId-injection delta — same approach as Epic #763 (scheduler).

OSS-side additions (not deviations)

• No enterprise auth/tag dependencies. Resource is unauthenticated in OSS, matching how the rest of /api/* works in OSS today.

UI

The conductor UI already implements input/output schema pickers for Simple Task (and other task types where taskDef.inputSchema / outputSchema apply), and already calls /api/schema to populate them. Against an OSS server those calls 404, so the feature is currently hidden behind a flag.

Required UI work once the backend lands:

• Remove the feature flag gating the schema picker on Simple Task and any other task-definition forms that use it.
• Confirm the Schema management page (list / create / edit / version / delete) works end-to-end against OSS, with no Orkes-only UI affordances leaking through (tags, RBAC controls, etc.).
• Verify dropdowns that pull ?short=true schema lists render correctly with the OSS payload.

User impact

First-time users who try to attach an input/output schema to a Simple Task in the UI currently hit a broken picker, or the feature is hidden entirely. After this epic lands, schema management works end-to-end on an OSS server, matching the experience users get on Orkes.

Success Criteria

• POST/GET/DELETE /api/schema work against an OSS server with parity to Orkes payloads
• Postgres + MySQL persistence with Testcontainers coverage
• UI Simple Task input/output schema picker works against OSS without a feature flag
• UI Schema management page works end-to-end against OSS
• DAO interface matches Orkes signatures (orgId-aware); Orkes can adopt OSS module with minimal delta
• No enterprise dependencies leak into OSS module