[2.0] Unconfirm at transmission is not reflected (Under certain conditions)

[mizunashi]

Environment: MacOS Latest & Universal version.
I think that it is the same in other environments.

Expected Behavior

When transmitting a NanoWallet, if the transaction becomes Unconfirm, "Tin!" Sounds.

Current Behavior

If the NanoWallet is open for a long time, the sound (Tin!) At the time of remittance is not sounded when it becomes Unconfirm.
And it is not reflected in Unconfirm.
It occurs at a high frequency.

Possible Solution

The current countermeasure that you can do is to change Node.
That will correctly recognize Uncomfirm.
Is WebSocket expired?

Steps to Reproduce

1. Log in to the NanoWallet.
2. Leave it for a long time.
3. Make money transfer. (send)
4. It is not displayed in Unconfirm and no sound is heard.
   (Important) There is not a problem with first selected Node

Details

UPnP is not used, so I think it is a session relationship.
Imagine if WebSocket will expire if it is a long time.
It may be better to set the port of WebSccket as a router so that it can be accessed from the outside.
What do you think of this idea?

• Donation Address: NCVGXT-CV7YYG-CUTOWR-SEALEV-HVTDFR-J54BQY-DKTI
• NEM Membership ID: NEM-000616

[yaaccount]

I investigated this for two evenings on the testnet and this is what I have found:

Call of nem.com.websockets.requests.account.transactions.recent initiated from dataBridge.service.js during connecting to a new node triggers also delivering of unconfirmed transactions on "/unconfirmed/

" websocket subscription/channel (subscribed via nem.com.websockets.subscribe.account.transactions.unconfirmed)

Interestingly, it triggers it also for other clients connected to the same NIS (testnet) node!!!

(I don't know if this is a NIS bug or feature)

This could be used to create a "workaround" - just call nem.com.websockets.requests.account.transactions.recent in a loop (i.e. every 10-20s, from dataBridge.service.js, use another injected parameter $interval; I tried that, works like a charm)

nem.com.websockets.requests.account.transactions.recent in a loop has a disadvantage - it also deliveres last 25 transactions on /recenttransactions/

channel, which could get costly; better would be to implement nem.com.websockets.requests.account.transactions.unconfirmed, directly in nem-sdk (account.js; I tried also that, works like a charm, too)

I think this could solve several recuring issues where unconfirmed (multisig) transactions are involved.

Notes:

1. It would be nice if someone else confirmed my observation first. @tongokongo? @cryptoBeliever?
2. Could you add incomming/outgoing/unconfirmed calls into nem-sdk (it is copy-pasting, anyway) @QuantumMechanics ?

[yaaccount]

Ok, this is getting even weirder.

Setup: I have two cosigners, on different machines, both are logged in (both are subscribed to websockets), each uses different node.

a) 1st cosigner initiates the transaction from slave account to self (so it is both initiator and recipient). It is not indicated in the "unconfirmed" tab anywhere.
b) 2nd cosigner changes the node to match the 1st cosigners node; ding! 1st cosigner has now unconfirmed transaction (and I can see in the ws logs that 1st cosigners websocket subscriptions received data), 2nd cosigner still nothing (and form his POV, I replicated the behaviour described in #558); everytime he changes node away and back to match the 1st cosigners node, 1st cosigner receives unconfirmed transactions from websocket

That means: one clients call to nem.com.websockets.requests.account.transactions.recent causes update on another client! That can result in total undeterministic mess. There is definitely something very wrong in how NIS handles websocket connections/channel subscriptions.

Could someone from NIS side (pretty please) shed some light in here? @BloodyRookie ? @Jaguar0625 ?

[yaaccount]

Update:
If I log in as 2nd cosigner twice, than change of the node from one instance adds another set of subscriptions on the open/active websocket in the other instance. Repeat 10x => 10 sets of subscriptions, all of them receiving updates.