# `DragOptions.commit`

> Contract 2.0.0 · package sha256 `a857eca95b35921109faf997094bb4192f12527d9d0fcd4be7e97f06425bad6e` · generated from `configurator-runtime.d.ts` by `services/onsite-scripter/scripts/build-contract-docs.mjs`; edit the source, not this file.

Property of [`DragOptions`](DragOptions.md) · stable · since 2.0.0

```ts
commit?: 'runtime' | 'app';
```

'runtime': at release the runtime writes the pose to the scene model (one recorded commit,
actor 'shopper'), which enters the write queue then, behind any scene write called before
(spec section 6.1, O2a); it counts as called then, so a history group open at release takes
it into its step (O14). A release before the drag's 'drag:start' dispatched (press to release
within one frame) dispatches that 'drag:start' and its queued 'drag:move's at the release,
first, so a group its handlers open takes the drop too (R2-PLN-2). Until it applies, the unit keeps the last constrained pose as a held
pose, as with 'app', so the drop never snaps back while an earlier sync loads; a commit ahead
of it that removes, disables or deselects the node releases it (ID5), and the drop's commit
then writes nothing at its turn: no pose, feed entry, step or Problem (spec section 6.4). If that commit fails
inside the runtime, it rolls back, records 'sync-failed' with its `op` and releases the held
pose, so the unit shows its scene-model pose from the next frame (spec section 6.4).
'drag:end' carries that `op`: the drop committed when a feed entry's `cause.op` equals it, and
rolled back when a 'sync-failed' Problem's `op` does (its `node` is the unit's); an equal drop
records neither (spec section 6.1, O15).
A collection item has no
scene-model pose, so a 'runtime' registration matches scene-model parts only, and [`input.drag`](Input.drag.md)
throws HoloInputError('invalid-input') when its query names a `collection` or `key` without
'app': an item is dragged with 'app' and placed by [`Collection.set`](Collection.set.md).
'app': the runtime writes nothing; the unit keeps the last constrained pose
until a commit changes that node's pose in the scene model or removes, disables or deselects the
node (ID5), or [`input.revert(part)`](Input.revert.md). A collection item is released the same way by a commit
that changes its `at` or removes it ([`Collection.set`](Collection.set.md), or [`apply`](Writer.apply.md) with `collections`). A commit
that rewrites the node or the item unchanged does not release it, nor does removing the
registration, so re-arming after a drop never snaps the unit back. A pending write that would
change that pose or `at` but is superseded (spec section 6.1, O2c) passes the release to the
write that superseded it, which releases the unit when it resolves 'committed', equal or not,
so a store undo whose sync overtakes the drop's sync shows the scene model's pose. A
node that comes back (an undo, or the same `nodeId` added again) shows its scene-model pose. A
[`Frame.pose`](Frame.pose.md) on the unit wins over the held pose while both live (R1), so an app can animate a
released unit away (a planner's drag-out-to-delete). Until it is released, the held pose is
the unit's observed pose for every derived read (`worldPose`, `bounds()`, connector positions),
so a drop check after 'drag:end' measures where the unit shows; [`state()`](Writer.state.md) and
[`getSceneModel()`](Writer.getSceneModel.md) keep the scene model's pose. A commit that would release it and lands between
the pointer's release and the 'drag:end' dispatch (an undo, an earlier sync) updates the scene
model but releases the hold no earlier than that dispatch, so the handler always sees the held
drop pose; the unit shows the committed pose from the frame after it. The value 'app' is labs and experimental:
guard it with [`has(session, 'input.drag.commit.app')`](has.md), which also brings [`input.revert`](Input.revert.md), the
call that ends a refused drop.

**Default:** 'runtime'

## Generic-API test (spec 3.1)

| Rule | Result |
| --- | --- |
| 1. Neutral name | pass: `commit` names no product |
| 2. A precedent | pass: [Babylon.js PointerDragBehavior (startDrag, onDragObservable, validateDrag)](https://github.com/BabylonJS/Babylon.js/blob/master/packages/dev/core/src/Behaviors/Meshes/pointerDragBehavior.ts) (row `G1`); [jQuery UI draggable (drag, revert)](https://api.jqueryui.com/draggable/) (row `G1`) |
| 3. Two apps, or labs | pass: 5 apps (ledger: app-04c2774145, app-37356bf09f, app-4762caacdc, app-fc07850558, app-fc306ec3dc) |
| 4. The cheaper fix first | decided per need in Appendix B: rows `G1`, `K47` at tier labs, stable (a member only where no rule, data, asset or app code serves the need) |