v0.13.0

[AsamK]

Attention: Now requires Java 21 and libsignal-client version 0.39.2

Breaking changes

• Sending to the self number (+XXXX) now behaves the same as the --note-to-self parameter. To get the previous
  behavior with notification, the --notify-self parameter can be added.

Added

• New --hidden parameter for removeContact command
• New --notify-self parameter for send command, for sending a non-sync message when self is part of the recipients
  or groups.
• New --unrestricted-unidentified-sender, --discoverable-by-number, --number-sharing, --username
  and --delete-username parameter for updateAccount command
• New --bus-name parameter for daemon command to use another D-Bus bus name
• New getAvatar and getSticker commands to get avatar and sticker images
• New sendMessageRequestResponse command to accept/delete message requests

Fixed

• Improve issue with stale prekeys and receiving messages to PNI address

Improved

• Better shutdown handling after Ctrl+C and SIGTERM
• Implemented full remote storage sync.
  Provides better contact and settings sync for linked devices.
• listContacts doesn't list unregistered users anymore

What's Changed

• Example syntax for a mixed text style by @spezialist1 in Example syntax for a mixed text style #1367
• add file.encoding=UTF-8 to native builds, refs Special characters in message text not working (anymore) #1105 by @morph027 in add file.encoding=UTF-8 to native builds, refs #1105 #1404
• Bump h2 from 0.3.21 to 0.3.24 in /client by @dependabot in Bump h2 from 0.3.21 to 0.3.24 in /client #1418

New Contributors

• @spezialist1 made their first contribution in Example syntax for a mixed text style #1367

Full Changelog: v0.12.8...v0.13.0

---

This discussion was created from the release v0.13.0.

[mgForPg]

Better shutdown handling after Ctrl+C and SIGTERM
now when running in jsonrpc daemon mode after sending CTRL-C an additional "\r\n" appears to be needed to terminate the process.
Is this the desired behavior?

[AsamK]

That's not desired behavior, but I also can't reproduce it.
Which command are you using exactly, which OS, which signal-cli build? And a verbose log might show more details (-vv)

[mgForPg]

I'm working on W10, jdk 21.0.2 LTS, signal-cli 0.13.0

I've a c++ program that starts signal-cli with CreateProcess (without window and replacing STDIN/STDOUT).
The following tests were done leaving the default console attached to the process.
This is the command line (CLASSPATH and NUMBER are expanded at runtime):
"C:\Program Files\Java\jdk-21\bin\java.exe" -classpath "CLASSPATH" org.asamk.signal.Main -a NUMBER jsonRpc

To close program I attach a console to process and send CTRL_C_EVENT, something like this:

AttachConsole(g_idChildProcess)
GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0);
FreeConsole();	

this is the verbose log

2024-02-23T17:22:08.524+0100 [receive-0] DEBUG o.a.s.manager.internal.JobExecutor - Running CleanOldPreKeysJob job
2024-02-23T17:22:08.526+0100 [pool-2-thread-1] TRACE o.a.s.m.jobs.CleanOldPreKeysJob - Cleaning old prekeys
2024-02-23T17:22:08.526+0100 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Checking for new message from server
//Send  CTRL_C_EVENT
2024-02-23T17:22:27.879+0100 [SIGINT handler] INFO  org.asamk.signal.Shutdown - Received SIGINT signal, shutting down ...
2024-02-23T17:22:27.880+0100 [SIGINT handler] DEBUG org.asamk.signal.Shutdown - Triggering shutdown.
//Here i have to press ENTER to continue shutdown
//Until I press ENTER on console service seems to continue working
2024-02-23T17:22:38.505+0100 [Thread-1] INFO  LibSignal - [WebSocketConnection]: [normal:84440414] Sending keep alive...
2024-02-23T17:22:38.517+0100 [Thread-1] INFO  LibSignal - [WebSocketConnection]: [unidentified:1834729958] Sending keep alive...
2024-02-23T17:23:08.530+0100 [Thread-1] INFO  LibSignal - [WebSocketConnection]: [normal:84440414] Sending keep alive...
2024-02-23T17:23:08.531+0100 [Thread-1] INFO  LibSignal - [WebSocketConnection]: [unidentified:1834729958] Sending keep alive...
2024-02-23T17:23:08.553+0100 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Checking for new message from server
//Press ENTER
2024-02-23T17:23:13.725+0100 [main] TRACE org.asamk.signal.util.IOUtils - Line supplier has been interrupted.
2024-02-23T17:23:13.725+0100 [main] TRACE o.asamk.signal.jsonrpc.JsonRpcReader - Reached end of JSON-RPC input stream.
2024-02-23T17:23:13.726+0100 [main] DEBUG o.a.s.manager.internal.ManagerImpl - Receive stop requested, interrupting read from server.
2024-02-23T17:23:13.726+0100 [receive-0] DEBUG o.a.s.manager.helper.ReceiveHelper - Handling message actions
2024-02-23T17:23:13.726+0100 [main] INFO  LibSignal - [WebSocketConnection]: [normal:84440414] disconnect()
2024-02-23T17:23:13.727+0100 [main] INFO  LibSignal - [WebSocketConnection]: [unidentified:1834729958] disconnect()
2024-02-23T17:23:13.727+0100 [receive-0] DEBUG o.a.s.manager.internal.ManagerImpl - Finished receiving messages
2024-02-23T17:23:13.728+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown initiated...
2024-02-23T17:23:13.730+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown completed.
2024-02-23T17:23:13.732+0100 [Thread-0] DEBUG org.asamk.signal.Shutdown - JVM is shutting down
2024-02-23T17:23:13.732+0100 [Thread-0] DEBUG org.asamk.signal.Shutdown - Waiting for app to shut down
2024-02-23T17:23:13.732+0100 [Thread-0] DEBUG org.asamk.signal.Shutdown - Exiting

If it can be useful I did other tests and verified that a similar thing happen if I launch from the command line using this (after setting %CLASSPATH% correctly)

c:\>java.exe -classpath "%CLASSPATH%" org.asamk.signal.Main -a %NUMBER% jsonRpc

The system launch the java.exe located in C:\Program Files\Common Files\Oracle\Java\javapath_target_10551593 (installed by jdk setup)
which spawn the process C:\Program Files\Java\jdk-21\bin\java.exe (with the same arguments).
When I press CTRL-C process end but you need to press ENTER to return to the command line prompt.
Starting C:\Program Files\Java\jdk-21\bin\java.exe directly CTRL_C event work correcly.

Using the previous version 0.12.8 the process ends after pressing CTRL-C without further input in all cases described.
Related to this, do you think it might be useful to provide a json packet to request the shutdown of the service?

[AsamK]

Maybe interrupting the read function doesn't work on Windows, I can only test on Linux.
Can you close the stdin stream you pass to signal-cli, that should also terminate jsonRpc command.

[mgForPg]

Can you close the stdin stream you pass to signal-cli, that should also terminate jsonRpc command.

much simpler and it works :)
thanks a lot