Skip to main content
Running operations with bijection run and the console’s Operations page are in beta.
The CLI and the console present each operation as one entry, under its own name, rather than as the companion functions that serve it. They use the same request keys, previews and recovery described in Calling operations.

​
Running an operation

bijection run recognizes an operation from your deployment and submits it:
The command:
1

Submits the request

It generates a fresh request key, unless you pass --request-key, and prints the acceptance: the invocation ID and the request key.
2

Follows its status

It subscribes to the request’s status until nothing is pending, then prints what was established, for example Local changes committed; provider changes confirmed and published.
3

Stops where waiting cannot help

An unknown or unacknowledged provider outcome is reported as not confirmed instead of being waited on. If a person must decide before the request can continue, the command says so, prints the command to resume following it later, and exits normally.
Keep the request key it prints. It is how you recover the request later.

​
Options for operations

--recover must be given the same arguments as the original request. --watch and --inline-query do not apply to operations and are refused with a reason: a query is watched, while an operation is submitted once and followed through its status.
Every caller of an operation needs a grant, including a deployment administrator. Without one, bijection run is refused with OperationAccess. See Granting access.

​
Following requests in the logs

bijection logs prints each companion’s log lines under the operation’s own name. With --operations, it streams accepted requests, their review state and their external-call outcomes instead of function log lines:
--held and --blocked require --operations and cannot be combined. A request that stops being held simply stops appearing; the listing reports a selection, not a transition. A request listed by --blocked has an external call whose delivery is currently refused, for example because its integration command changed after the request was accepted. When that call was never sent, re-admit it with bijection run <operation> --revise --invocation-id <id>.

​
Inspecting an external call

A deployment administrator can inspect and recover one external call by its ID:
Recovery keeps the call’s accepted identity. It interprets retained evidence or performs a bounded read, and it never submits a new write. Read on about unknown outcomes.

​
The Operations page

In the console, a deployment’s Operations page has two tabs. Definitions lists each deployed operation with its object type. Select one to fill in its arguments, with a form or as JSON, preview the changes, and submit. The page keeps the request key of each submission, so after an uncertain outcome its button becomes Recover or retry this request. That first looks up the retained request, and only then retries it under the same key and arguments. It never creates a new request. Activity lists accepted requests. The Show selector chooses:
  • All requests
  • Held for review: requests waiting for a review decision
  • External work refused: requests with external work that needs to be resolved
Needs attention on this page narrows the current page to requests 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. Select a request to see its review state and each external call’s outcome. For an external call whose outcome is unconfirmed, the request’s detail shows the retained evidence and a Check retained evidence button. Checking evidence never submits a new request, and an outcome that stays unconfirmed is shown as unconfirmed.
The console shows why a request is held and who must decide, but it has no approve or reject button. Decisions are made by your own review operation, under your access rules.
The Functions and Logs pages also show one entry per operation, under its own name.