Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions packages/azure-functions-durable/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,8 +42,11 @@ changed:
`context.df.isLocked()` and the `DurableLock` / `LockState` / `LockingRulesViolationError` exports
are removed. Acquire locks with the core `context.entities.lockEntities(...entityIds)` (returns a
`LockHandle` — call `release()`, ideally in a `finally`) and query with
`context.entities.isInCriticalSection()`. Restoring the v3 `df.lock` / `isLocked` surface is tracked
in [#317](https://github.com/microsoft/durabletask-js/issues/317).
`context.entities.isInCriticalSection()`. This is the permanent, supported API — the v3 `df.lock` /
`isLocked` surface (and the `DurableLock` / `LockState` / `LockingRulesViolationError` types) will
**not** be restored; use the core `context.entities.*` lock API instead. See
[#317](https://github.com/microsoft/durabletask-js/issues/317) for the cross-SDK rationale (the
Python SDK ships only this core-native lock API and never exposed a `df.lock` / `is_locked` surface).
- **`context.df.callHttp(...)` now throws.** v3 ran durable HTTP as a host-managed activity; the
consolidated gRPC backend has no equivalent primitive. Implement an HTTP activity in your app and
call it from the orchestrator. Restoring `callHttp` as a worker-side durable activity is tracked in
Expand Down
Loading