pub async fn request_bpmn_instance_migration(
configuration: &Configuration,
workspace: &str,
id: &str,
request_bpmn_instance_migration_request: RequestBpmnInstanceMigrationRequest,
) -> Result<BpmnMigrationRequested, Error<RequestBpmnInstanceMigrationError>>Expand description
The write half of the mapped migration contract (#925, stage 4). Resolves the mapping against this instance’s own pin exactly as planBpmnInstanceMigration does and, only if it resolves to a plan, writes a migration request into process_status.control.migrate and pulls an existing park forward so the engine re-pulls the instance promptly. Validate-then-write in one transaction: a mapping that does not hold leaves nothing behind. Unlike migrateBpmnInstance this does not perform the migration. A mapped migration rewrites process_status, which the engine owns, so the pin move, the blob rewrite and the bpmn_instance_migration ledger row all happen together in the engine’s next step. A 200 here means the request was accepted and stored, not that the instance has moved – poll the pin, or the instance’s status, to observe it. The stored request carries the mapping document, never the resolved plan. A plan is a bare identifier substitution, so a control entry carrying one would let anything able to write the control channel substitute arbitrary identifiers into a running instance; the engine re-derives the plan from the document against the two definitions it actually resolved. The plan in this response is informational. The engine can still refuse what this accepts, for the one reason that is not a property of the version pair: an activity Started on a renamed element holds a live child job id derived from the source id. That is refused at apply time and the signal is that the pin did not move. Everything that is a model-vs-model property, including rule 9 (vacating an identifier the target still defines), is refused here with a 400.