Operations

A deployment’s Operations page lists the deployment’s operations and the requests it accepted. You can fill in and preview an operation, submit it, recover a submission whose response was lost, and follow each accepted request through review, delivery and publication. It uses the same request keys, previews and recovery as bijection run and your own callers. The page has two tabs, Definitions and Activity. For a deployment with components, the selector at the top right chooses the component.

​

Running operations as

The Run operations as panel at the top shows the identity the page’s requests run as: Deployment administrator by default. Open it and check Act as an application user to enter a user identity as JSON and click Use this identity; this needs permission to act as a user. The identity is remembered in the browser tab and shared with the Files page. Changing it opens a separate request context: requests retained under one identity are never sent as another. The identity decides what the deployment lets these requests do and see. Every caller of an operation needs a grant on it, including a deployment administrator; without one, a submission is refused with OperationAccess. See Granting access.

​

Definitions

The Definitions tab lists each deployed operation with its object type. When none is deployed, it shows No operations deployed. Select an operation to open it. The page shows its object type and whether it is public or internal, links to its deployed function on the Functions page, and View definition shows the object type’s definition. Enter the arguments in Inputs, a JSON editor checked against the operation’s argument validator, or in a form where one is declared for the operation (Advanced inputs (JSON) switches to the editor). Validation errors are listed below the inputs. Other pages open this tab too. On the Data page, a view’s Operations link shows only that object type’s operations, and a definition panel links each of its operations. From a record, an operation that declares a target opens with the record’s ID already filled in.

​

Previewing

For an operation with a preview, Preview changes evaluates it on the current data without accepting anything or sending any request. The result says whether the preview checks are satisfied, found an execution restriction, or could not be evaluated completely, and lists the checks, the proposed local changes with each row before and after, and the proposed external requests, which were not sent. When some effects can’t be shown to you, the result says the display is limited. Native report and provisional basis shows the whole report. Submitting checks current facts and permissions again. See Previewing an operation.

​

Submitting and recovering

Submit operation sends the request. Before sending, the page keeps a request key and the exact arguments in the browser tab, per deployment, component, operation and identity, and it refuses to send a request it could not keep.

• When the deployment accepts, the page shows Local changes committed. and the request’s detail, as on the Activity tab. Start a new request clears the kept request.
• When the response is lost, the page shows Acceptance not yet confirmed, never a failure, because the request may still commit. The button becomes Recover or retry this request. It first looks up what the kept key already accepted, and only if nothing was accepted sends the request again under the same key and arguments. It never creates a new request.

A kept request survives a reload of the tab. Opening the operation again first checks for it (Checking for an interrupted request…), and while one is kept its inputs are locked and shown under Retained request inputs with its key. Submit operation is disabled without permission to write data, for an internal operation without permission to run internal mutations, when acting as a user without permission to act as a user, and for an unmounted component. Result contract shows the operation’s result validator.

​

Activity

The Activity tab lists the accepted requests the selected identity may see, newest first. Show chooses the list, selected by the deployment:

• All requests
• Held for review: requests waiting for a review decision
• External work refused: requests with an external call whose delivery is currently refused

Needs attention on this page narrows the current page to requests whose retained result expired, that await a review decision, or that have an external call whose outcome is not confirmed, was refused, did not take effect or was executed more than once, or whose publication is blocked. Each row shows the operation, the retained state (Accepted or Retained result expired), a summary of the outcome, the review state and the reason it needs attention, and the invocation ID. The summary keeps local acceptance separate from what the provider confirmed, for example Local changes committed; provider outcome is not confirmed. Lists are paged with Next page and First page; a page of a selected list can be short or empty with more behind it. Activity targeting this object, on a record in the Data page, opens this tab with only the requests aimed at that record. The Operations card on the Overview page links here too.

​

A request’s detail

Click a request to see its detail. It is read through the operation’s status under the selected identity, so a request whose result you may not see shows the refusal instead.

• Review shows the review state and its facts, such as the blocker, who is responsible and since when. The page has no approve or reject control: a decision is made by your application’s own review operation, under its own rules, and the page links to that operation when it is deployed.
• For each external call, Write progress shows three steps: accepted, the provider’s answer (confirmed, refused, outcome unknown or awaited) and whether the confirmation was recorded. The call’s delivery state and publication follow.
• Recovery guidance and revisions, on a request with a refused external call, gives the command that re-admits a never-held call under the current definitions, bijection run <operation> --revise --invocation-id <id>, and the contract, code and policy revisions it was accepted under. See Revising a blocked request.

​

Provider outcome

Under each external call, the Provider outcome section shows the original request, the requested change and table, the connection and source, the outcome, the number of attempts, the last HTTP status and when the response was observed. It explains the outcome and, where it applies, that:

• automatic attempts stopped at the delivery deadline, the attempt limit or the response limit;
• the provider asked the connection to wait for an operator, or its readiness statement could not be read;
• current authority no longer permits recovery;
• the request is held, and should be checked before it is released.

When the outcome is unconfirmed, the section is titled Review an unconfirmed change and says to keep the request, compare the retained evidence with the provider’s own audit trail, and not submit a replacement. Check retained evidence, offered for an unknown or held outcome, is bijection integration command-recover: for this same request, it interprets the retained evidence or performs a bounded read, and never sends a new write. An outcome that stays unconfirmed is shown as unconfirmed. It needs permission to write data and is disabled when authority changed. Retained evidence and technical details shows how many response bytes are retained, their SHA-256 and any provider refusal; credentials and response contents are never shown. A completed change that needs repair is a separate business operation, reviewed against current provider facts. See Unknown outcomes and recovery.

​

Permissions

A control you lack permission for is shown disabled, and the deployment checks the same permissions itself. The operation’s own grants and access rules apply on top of these. Admins and Developers hold all four; Viewers can read the page but submit nothing. See Role Actions.