docs(web/guides): abort inside a Wheels transaction rolls back on BoxLang

web/sites/guides/src/content/docs/v4-2-0/upgrading/4x-1-to-4x-2.mdx

@@ -328,6 +328,10 @@ On SQLite, a date passed to the query builder (`where()`, `whereBetween()`, `whe
 
 `enqueue()`, `enqueueIn()` and `enqueueAt()` throw `Wheels.Job.EnqueueFailed` when the job can't be written to the job store ([#4266](https://github.com/wheels-dev/wheels/pull/4266)). In 4.1 they returned a struct with `persisted: false`, which was easy to miss, so failed enqueues went unnoticed. Don't read `persisted: false` as a failure any more: a job deferred to a commit (next section) also returns it. Replace `persisted` checks with a check of `status` (`"pending"` once written, `"deferred"` until the commit) where you need one, and where an enqueue is best-effort, wrap it in `try` / `catch (Wheels.Job.EnqueueFailed e)`.
 
+### `abort` inside a Wheels transaction rolls it back on BoxLang too
+
+A request that ends with `abort` inside a Wheels transaction (`invokeWithTransaction()`, a nested call that joins it, or a savepoint unit) now rolls that transaction back on BoxLang, as it already did on Lucee and Adobe ColdFusion. On BoxLang, 4.1 kept the writes made before the `abort`. If a BoxLang app relies on those writes, let the transaction finish (return from the method) before it aborts. Raw `transaction {}` blocks aren't managed by Wheels and are unchanged.
+
 ### A job enqueued in a transaction on another datasource waits for the commit
 
 Inside a Wheels-managed transaction (a model save or `invokeWithTransaction()`) on another datasource than the job store's, the job is now written when the transaction commits, and dropped if it rolls back ([#4282](https://github.com/wheels-dev/wheels/pull/4282)). That's a tenant datasource under `TenantResolver`, or a model with its own `dataSource()`. In 4.1, depending on the engine, such a job could survive a rollback, land in the tenant's database where no worker reads it, or not be written at all. `enqueue()` then returns `{status: "deferred", deferred: true, persisted: false}`. That `persisted: false` is not a failure; check `status` instead. A write that fails after the commit throws `Wheels.Job.EnqueueFailed`, and the saved record stays committed. A raw `transaction {}` block isn't tracked, so enqueue after it ends. See [Background jobs: with a tenant datasource](/v4-2-0/digging-deeper/background-jobs/#with-a-tenant-datasource).