8b58b16cb5
I used some AI to draft a first version of this, and then reworked it. This is one of multiple possibilities to fix https://github.com/chatmail/core/issues/8041: For bots, the IncomingMsg event is not emitted when the pre-message arrives, only when the post-message arrives. Also, post-messages are downloaded immediately, not after all the small messages are downloaded. The `get_next_msgs()` API is deprecated. Instead, bots need to listen to the IncomingMsg event in order to be notified about new events. Is this acceptable for bots? THE PROBLEM THAT WAS SOLVED BY THIS: With pre-messages, it's hard for bots to wait for the message to be fully downloaded and then process it. Up until now, bots used get_next_msgs() to query the unprocessed messages, then set last_msg_id after processing a message to that they won't process it again. But this will now also return messages that were not fully downloaded. ALTERNATIVES: In the following, I will explain the alternatives, and for why it's not so easy to just make the `get_next_msgs()` API work. If it's not understandable, I'm happy to elaborate more. Core can't just completely ignore the pre-message for two reasons: - If a post-message containing a Webxdc arrives later, and some webxdc updates arrive in the meantime, then these updates will be lost. - The post-message doesn't contain the text (reasoning was to avoid duplicate text for people who didn't upgrade yet during the 2.43.0 rollout) There are multiple solutions: - Add the message as hidden in the database when the pre-message arrives. - When the post-message arrives and we want to make it available for bots, we need to update the msg_id because of how the `get_next_msgs()` API works. This means that we need to update all webxdc updates that reference this msg_id. - Alternatively, we could make webxdc's reference the rfc724_mid instead of the msg_id, so that we don't need stable msg_ids anymore - Alternatively, we could deprecate `get_next_msgs()`, and ask bots to use plain events for message processing again. It's not that bad; worst case, the bot crashes and then forgets to react to some messages, but the user will just try again. And if some message makes the bot crash, then it might actually be good not to try and process it again. - Store the pre-message text and `PostMsgMetadata` (or alternatively, the whole mime) in a new database table. Wait with processing it until the post-message arrives. Additionally, the logic that small messages are downloaded before post-messages should be disabled for bots, in order to prevent reordering.
deltachat-jsonrpc
This crate provides a JSON-RPC 2.0 interface to DeltaChat.
The JSON-RPC API is exposed in two fashions:
- A executable
deltachat-rpc-serverthat exposes the JSON-RPC API through stdio. - The JSON-RPC API can also be called through the C FFI. It exposes the functions
dc_jsonrpc_init,dc_jsonrpc_request,dc_jsonrpc_next_responseanddc_jsonrpc_unref. See the docs in the header file for details.
We also include a JavaScript and TypeScript client for the JSON-RPC API. The source for this is in the typescript folder.
Usage
Using the TypeScript/JavaScript client
The package includes a JavaScript/TypeScript client which is partially auto-generated through the JSON-RPC library used by this crate (yerpc). Find the source in the typescript folder.
To use it locally, first install the dependencies and compile the TypeScript code to JavaScript:
cd typescript
npm install
npm run build
The JavaScript client is published on NPM.
A script is included to build autogenerated documentation, which includes all RPC methods:
cd typescript
npm run docs
Then open the typescript/docs folder in a web browser.
Development
Running the example app
Testing
The crate includes both a basic Rust smoke test and more featureful integration tests that use the TypeScript client.
Rust tests
To run the Rust test, use this command:
cargo test
TypeScript tests
cd typescript
npm run test
This will build the deltachat-jsonrpc-server binary and then run a test suite.
The test suite includes some tests that need online connectivity and a way to create test email accounts. To run these tests, set the CHATMAIL_DOMAIN environment variable to your testing email server domain.
CHATMAIL_DOMAIN=ci-chatmail.testrun.org npm run test
Test Coverage
Running npm run test will report test coverage. For the coverage to be accurate the online tests need to be run.
If you are offline and want to see the coverage results anyway (even though they are inaccurate), you can bypass the errors of the online tests by setting the
COVERAGE_OFFLINE=1environment variable.
A summary of the coverage will be reported in the terminal after the test run. Open coverage/index.html in a web browser for a detailed report.