Skip to content

fix: remove internals from outbox api #2096

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Sep 19, 2025
Merged

fix: remove internals from outbox api #2096

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3180716
review outbox api
sjvans Sep 17, 2025
fada5d9
rm options
sjvans Sep 17, 2025
1e85ba1
Merge branch 'main' into outbox-api
sjvans Sep 18, 2025
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
22 changes: 2 additions & 20 deletions node.js/queue.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ The _task queue_ feature can be disabled globally via <Config>cds.requires.queue
### cds. queued (srv) {.method}

```tsx
function cds.queued ( srv: Service, options? ) => QueuedService
function cds.queued ( srv: Service ) => QueuedService
```

Programmatically, you can get the queued service as follows:
Expand All @@ -47,18 +47,6 @@ await qd_srv.send('someEvent', { some: 'message' }) // asynchronous
You still need to `await` these operations because they're asynchronous. In case of a persistent queue, which is the default, messages are stored in the database, within the current transaction.
:::

The `cds.queued` function can also be called with optional configuration options.

```js
const qd_srv = cds.queued(srv, { maxAttempts: 5 })
```

> The persistent queue can only be used if it is not disabled globally via `cds.requires.queue = false`, as it requires a dedicated database table.

::: warning One-time configuration
Once you queued a service, you cannot override its configuration options again.
:::

For backwards compatibility, `cds.outboxed(srv)` works as a synonym.


Expand Down Expand Up @@ -89,9 +77,7 @@ You can configure the outbox behavior by specifying the `outboxed` option in you
"requires": {
"yourService": {
"kind": "odata",
"outboxed": {
"maxAttempts": 5
}
"outboxed": true
}
}
}
Expand All @@ -115,8 +101,6 @@ Using the persistent queue, the to-be-emitted message is stored in a database ta
"queue": {
"kind": "persistent-queue",
"maxAttempts": 20,
"parallel": true,
"chunkSize": 10,
"storeLastError": true,
"legacyLocking": true,
"timeout": "1h"
Expand All @@ -128,8 +112,6 @@ Using the persistent queue, the to-be-emitted message is stored in a database ta
The optional parameters are:

- `maxAttempts` (default `20`): The number of unsuccessful emits until the message is considered unprocessable. The message will remain in the database table!
- `parallel` (default `true`): Specifies if messages are sent in parallel (faster, but the order isn't guaranteed).
- `chunkSize` (default `10`): The number of messages that are read from the database table in one go. Only applies for `parallel !== false`.
- `storeLastError` (default `true`): Specifies whether error information of the last failed emit is stored in the tasks table.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also rm storeLastError? Should we remove the legacyLocking completely and switch it to false?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imho, they can stay

- `legacyLocking` (default `true`): If set to `false`, database locks are only used to set the status of the message to `processing` to prevent long-kept database locks. Although this is the recommended approach, it is incompatible with task runners still on `@sap/cds^8`.
- `timeout` (default `"1h"`): The time after which a message with `status === "processing"` is considered to be abandoned and eligable to be processed again. Only for `legacyLocking === false`.
Expand Down
Loading