JMA

Version 1.0.0

Sep 2, 2026

API version: 9.10.0

Multi-tenancy step 1: every request must carry the trusted X-Tenant-Id header. All resources are stamped with the tenant they were created under; processing step queries are scoped to the caller’s tenant. Data created before multi-tenancy belongs to the tenant pinexq.
Persistence setup modes OnStartup (default), MigrateAndExit and VerifyOnly (PersistenceSetup:Mode), so schema migration can run as a deploy-time job while runtime pods only verify.
Boot-time schema setup is serialised across replicas with a PostgreSQL advisory lock.
GET api/Info reports the BuildVersion as the semantic version of the build, derived from the git tag (e.g. 1.0.0+<commit sha>). Container images are tagged with the same version (v1.0.0), the latest tag is no longer published.
Server-Sent Event delivery works across multiple replicas: API events are fanned out over a RabbitMQ fanout exchange so a client connected to one replica receives events produced on another. Off by default (ApiEventBackplane:Enabled; exchange RabbitMq:Exchanges:ApiEvents, default api-events-fanout), and single-replica behaviour is unchanged. Delivery is scoped by owner and tenant, failing open when a producer has no tenant context (e.g. a message-driven job update) so events are never dropped.

Portal-api base URLs and job logs/metrics links are resolved per tenant.
Registering a processing step rejects parameter schemas with deeply chained $ref definitions.
The job-update listener retries commands that hit a version conflict and rejects messages it cannot apply instead of acknowledging them blindly; rejected messages dead-letter into the durable queue Job.All.Updates.Rejected for inspection and replay.

Leaked RabbitMQ channels in the processing exchange.
Folder feature review findings (validation and navigation details).
Jobs no longer get stuck at Processing in the read model when the output cleanup of a completion races a concurrent update of the same job; the completion now starts from a clean unit of work.