Socket failure at MESSAGE(Cannot decrypt message: no suitable session found)

@Auties00 Probly a duplicate of https://github.com/Auties00/WhatsappWeb4j/issues/143

2022-06-26 22:26:39,207 |  WARN | Grizzly(1) | it.auties.whatsapp.binary.Socket | Socket failure at MESSAGE(Cannot decrypt message: no suitable session found)
2022-06-26 22:26:39,208 |  WARN | Grizzly(1) | it.auties.whatsapp.binary.Socket | Saved stacktrace at: /home/user/.whatsappweb4j/exceptions/1656275199207.txt
2022-06-26 22:26:39,208 |  WARN | Grizzly(1) | it.auties.whatsapp.binary.Socket | Ignoring failure

Stacktrace:

java.util.NoSuchElementException: Cannot decrypt message: no suitable session found
	at it.auties.whatsapp.crypto.SessionCipher.decrypt(SessionCipher.java:146)
	at it.auties.whatsapp.binary.Socket$MessageHandler.decode(Socket.java:1387)
	at it.auties.whatsapp.binary.Socket$MessageHandler.decode(Socket.java:1324)
	at it.auties.whatsapp.binary.Socket$MessageHandler.lambda$decode$34(Socket.java:1273)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at it.auties.whatsapp.binary.Socket$MessageHandler.decode(Socket.java:1273)
	at it.auties.whatsapp.binary.Socket$StreamHandler.digest(Socket.java:565)
	at it.auties.whatsapp.binary.Socket.handleNode(Socket.java:203)
	at java.base/java.lang.Iterable.forEach(Iterable.java:75)
	at it.auties.whatsapp.binary.Socket.onBinary(Socket.java:198)
	at jdk.internal.reflect.GeneratedMethodAccessor46.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:553)
	at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:652)
	at org.glassfish.tyrus.core.TyrusSession.notifyMessageHandlers(TyrusSession.java:560)
	at org.glassfish.tyrus.core.TyrusEndpointWrapper.onMessage(TyrusEndpointWrapper.java:800)
	at org.glassfish.tyrus.core.TyrusWebSocket.onMessage(TyrusWebSocket.java:183)
	at org.glassfish.tyrus.core.frame.BinaryFrame.respond(BinaryFrame.java:70)
	at org.glassfish.tyrus.core.ProtocolHandler.process(ProtocolHandler.java:819)
	at org.glassfish.tyrus.client.TyrusClientEngine$TyrusReadHandler.handle(TyrusClientEngine.java:725)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter$ProcessTask.execute(GrizzlyClientFilter.java:452)
	at org.glassfish.tyrus.container.grizzly.client.TaskProcessor.processTask(TaskProcessor.java:91)
	at org.glassfish.tyrus.container.grizzly.client.TaskProcessor.processTask(TaskProcessor.java:68)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter.handleRead(GrizzlyClientFilter.java:248)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:88)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:246)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:178)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:118)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:96)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:51)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:510)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:82)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:83)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:34)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:101)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:535)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:515)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.IllegalArgumentException: Key used already or never filled
	at java.base/jdk.internal.reflect.GeneratedConstructorAccessor41.newInstance(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
	at it.auties.whatsapp.util.Validate.createThrowable(Validate.java:29)
	at it.auties.whatsapp.util.Validate.isTrue(Validate.java:14)
	at it.auties.whatsapp.util.Validate.isTrue(Validate.java:9)
	at it.auties.whatsapp.crypto.SessionCipher.decrypt(SessionCipher.java:166)
	at it.auties.whatsapp.crypto.SessionCipher.tryDecrypt(SessionCipher.java:152)
	at it.auties.whatsapp.crypto.SessionCipher.decrypt(SessionCipher.java:131)
	... 38 more

These exceptions are coming “randomly” in the application log. Not that big of an issue but:

• is it possible to fix this or how can I fix it?
• Is there a way it is no longer written to a file, as this take unnecessary diskspace after a while?
• Can we configure the way exceptions are treated?

Setup

• Spring boot 2.6.6
• JDK 17.0.2
• whatsappweb4j 3.0-RC11

#Priority: Low

[Auties00]

Oh well, I played myself. I introduced this bug myself without even noticing it when I restructured the serialization process. I moved that logic inside a listener which was fired from a shutdown hook asynchronously. Obviously, this meant that the application couldn’t serialize its data as running async operations while your application is shutting down is the perfect way to avoid running it. I’m fixing it rn and will test further to see if this fixes the problem

[Auties00]

Are the messages deserialized correctly though? Like can you read all incoming messages despite this exception?

Well, not tested so far. Currently using only “api.sendMessage”.

so even more reason to assume that this “default” shouldn’t be a problem(or throws exceptions) right?

So I was testing and it looks like the bot disconnects at some point, reconnects and throws those errors. Interesting