ores.compute.workflow_batch_link
Table of Contents
When a submit_compute workflow step runs, the service creates a batch and records one row here that names the step and the step's instance. The bridge polls this table, and when the batch reaches a terminal state it publishes step_completed_event and deletes the row.
The table has no validity window and carries no audit tail: the row is a
note that a step is outstanding, and it is deleted rather than closed. The
model therefore states :current_state: and :no_audit_columns:.
The one decision the model records is the read scope. The bridge is a
service-level poller, not a caller acting for one tenant, so it reads
every tenant's links and deletes each under the tenant that owns it. That
is why the model states :tenant_read_scope: shared, which leaves the
tenant filter to row-level security rather than adding one on top, and
:rls_system_tenant_visible:, which is what lets the service's
system-tenant session see rows the tenant owns. Mutations stay
tenant-scoped, so the delete names the link's own tenant.
1. Flags
2. Columns
2.1. batch_id
The batch the step waits for. One step waits for one batch, so this column is the whole key.
2.2. workflow_step_id
The workflow step to complete when the batch finishes.
2.3. workflow_instance_id
The workflow instance the step belongs to.
2.4. created_at
When the link was recorded.
3. SQL
3.1. Flags
The two row-level-security flags do different jobs.
:rls_system_tenant_visible: states the policy: a system-tenant session
may read and write every tenant's rows.
:tenant_read_scope: shared states the C++ read: no tenant filter is
added on top, so the policy is what decides.
3.2. Indexes
| name | columns | unique | current_only | where_extra |
|---|---|---|---|---|
| workflow_batch_links_tenant | tenant_id | false | false |
4. Physical space
The table is internal. The bridge is the only reader and report_submit_handler the only writer, and neither reaches it over the wire, so only the data layer and the SQL schema are generated.
| Address | Enabled |
|---|---|
| ores.cpp.service | false |
| ores.cpp.protocol | false |
| ores.cpp.nats-handler | false |
| ores.cpp.nats-sub-registrar | false |
| ores.cpp.nats-event-registrar | false |
| ores.cpp.nats-eventing | false |
| ores.cpp.nats-event-cache | false |
| ores.cpp.history-provider-registrar | false |
| ores.cpp.presentation | false |
| ores.cpp.eventing-integration-test | false |
| ores.cpp.shell-command | false |
| ores.sql.schema.notify_trigger | false |
| ores.sql.schema.notify_trigger_drop | false |
| ores.ts.protocol | false |
| ores.ts.domain | false |
5. C++
5.1. Repository
The bridge reads every tenant's links, so the read states no tenant filter and the row-level-security policy is what decides. Mutations stay tenant-scoped, so the delete names the link's own tenant.
5.2. Domain includes
#include <chrono>
5.3. Conventions
6. See also
- ores.compute — component group overview.