PIN confirmation problem in send

lash commented

2024-09-12 00:15:26 +02:00

Owner

@Alfred-mk reports;

When doing PIN confirmation for send, the PIN is requested twice.

On http the confirmation fails after second time (even if PIN is correct)

On CLI it succeeds.

Apparently, similar PIN check works with balance check.

@Alfred-mk reports; When doing PIN confirmation for send, the PIN is requested twice. On http the confirmation fails after second time (even if PIN is correct) On CLI it succeeds. Apparently, similar PIN check works with balance check.

lash added the

Kind/Bug

Priority

High

labels 2024-09-12 00:15:26 +02:00

lash commented

2024-09-17 18:41:41 +02:00

Author

Owner

done

lash closed this issue

2024-09-17 18:41:41 +02:00

Alfred-mk commented

2024-09-21 01:00:45 +02:00

Member

I have done several tests on the "Send" node and "Change language". On the CLI, the menu flows without breaking. The rest either stall or return an error.

Running cmd/main.go

But this fails on africastalking, async and http

Running cmd/async/main.go and using a wrong PIN

Running cmd/async/main.go and using a correct PIN

Africastalking and http mimic the behavior of async
On cmd/main.go, the transaction PIN node is repeated if you use a valid PIN

I have done several tests on the "Send" node and "Change language". On the CLI, the menu flows without breaking. The rest either stall or return an error. Running cmd/main.go <img width="584" alt="image" src="attachments/d78cbd8f-b5a1-4831-895b-069d3ea0ab00"> But this fails on africastalking, async and http Running cmd/async/main.go and using a wrong PIN <img width="422" alt="image" src="attachments/f74e09e5-c0ed-4429-aabc-d642e3e526c5"> Running cmd/async/main.go and using a correct PIN <img width="425" alt="image" src="attachments/29739ee3-0b42-4493-9035-9d9754141689"> * Africastalking and http mimic the behavior of async * On cmd/main.go, the transaction PIN node is repeated if you use a valid PIN

image.png

48 KiB

image.png

33 KiB

image.png

43 KiB

Alfred-mk reopened this issue

2024-09-21 01:00:45 +02:00

Alfred-mk referenced this issue

2024-09-21 01:04:38 +02:00

AT sometimes asks for things twice #73

lash referenced this issue

2024-09-22 16:48:36 +02:00

AT sometimes asks for things twice #73

lash commented

2024-09-22 16:50:01 +02:00

Author

Owner

@Alfred-mk please rebase on #76 and try again.

It won't necessarily fix the issue, but would hopefully eliminate threaded access to db as potential problem source.

@Alfred-mk please rebase on #76 and try again. It won't necessarily fix the issue, but would hopefully eliminate threaded access to db as potential problem source.

Alfred-mk commented

2024-09-23 13:54:46 +02:00

Member

After comparing execution on cmd/main.go and cmd/async/main.go, it has been noted that LOAD statements are being executed each time they are encountered, causing the menu to display some nodes twice or more (such as PIN entries)

For example, if @code{LOAD} is called on node @file{foo/bar}, then execution descends to @file{foo/bar/baz} before returning to @file{foo/bar}, the second time the @code{LOAD} statement is encountered in @file{foo/bar} will have no effect.

This only happens on the cmd/main.go

All other binaries execute the LOAD and RELOAD even though one has not exited the menu.

After comparing execution on cmd/main.go and cmd/async/main.go, it has been noted that LOAD statements are being executed each time they are encountered, causing the menu to display some nodes twice or more (such as PIN entries) > For example, if @code{LOAD} is called on node @file{foo/bar}, then execution descends to @file{foo/bar/baz} before returning to @file{foo/bar}, the second time the @code{LOAD} statement is encountered in @file{foo/bar} will have no effect. This only happens on the cmd/main.go All other binaries execute the LOAD and RELOAD even though one has not exited the menu.

lash commented

2024-09-23 14:45:28 +02:00

Author

Owner

~~Ok, I see. So that has to do with persistence of the cache, then. Thanks.~~

in fact not, current node gets re-executed when moving out of it.

~~Ok, I see. So that has to do with persistence of the cache, then. Thanks.~~ in fact not, current node gets re-executed when moving out of it.

lash commented

2024-09-23 15:47:39 +02:00

Author

Owner

Related to #79