Executables not accessing the same state #23

New Issue

Open

opened 2025-02-19 11:37:53 +01:00 by Alfred-mk · 2 comments

Alfred-mk commented

2025-02-19 11:37:53 +01:00

Member

When running executables using the same session-id and connection string, it is expected that one would get the same state

Running the menu using cmd/main.go for session-id +254712345678 should result in the same menu gotten from cmd/africastalking/main.go

This is crucial as other executables rely on this principle, such as devtools/admin/main.go

Case examples

go build -tags logtrace,online -o sarafu-at -ldflags="-X main.build=${BUILD} -s -w" cmd/africastalking/main.go 

./sarafu-at

go build -tags logtrace,online -o sarafu-cmd -ldflags="-X main.build=${BUILD} -s -w" cmd/main.go  

./sarafu-cmd -session-id=+254712345678

These two executables will default to the defined DB_CONN and DB_CONN_RESOURCE strings in the .env

However, completing registration in the sarafu-at with the phoneNumber as +254712345678 will not allow you to proceed with the menu from the sarafu-cmd. Instead, one has to restart the registration

*After registration, both executables retain their own unique states, even after restart

When running executables using the same session-id and connection string, it is expected that one would get the same state Running the menu using cmd/main.go for session-id +254712345678 should result in the same menu gotten from cmd/africastalking/main.go This is crucial as other executables rely on this principle, such as devtools/admin/main.go ### Case examples ``` go build -tags logtrace,online -o sarafu-at -ldflags="-X main.build=${BUILD} -s -w" cmd/africastalking/main.go ./sarafu-at ``` ``` go build -tags logtrace,online -o sarafu-cmd -ldflags="-X main.build=${BUILD} -s -w" cmd/main.go ./sarafu-cmd -session-id=+254712345678 ``` These two executables will default to the defined DB_CONN and DB_CONN_RESOURCE strings in the .env However, completing registration in the `sarafu-at` with the `phoneNumber` as `+254712345678` will not allow you to proceed with the menu from the `sarafu-cmd`. Instead, one has to restart the registration #### *After registration, both executables retain their own unique states, even after restart

Alfred-mk added the

Kind/Bug

Priority

Critical

labels 2025-02-19 11:37:53 +01:00

Alfred-mk commented

2025-02-19 16:17:40 +01:00

Author

Member

What the `sarafu-at` and `sarafu-async` create (correct state)

What `sarafu-cmd` creates

The sarafu-cmd saves under <sessionId>.<sessionId> while sarafu-at and sarafu-async save under <sessionId>

The devtools/admin/main.go reads from the <sessionId>.<sessionId> resulting in an error when accessing account data created by sarafu-at

### What the `sarafu-at` and `sarafu-async` create (correct state) ![image](/attachments/00bf80e4-2e57-4770-88f6-e22012fdebaf) ### What `sarafu-cmd` creates ![image](/attachments/20fc707c-fcbf-4356-8865-4a93f7aff6f7) The `sarafu-cmd` saves under `<sessionId>.<sessionId>` while `sarafu-at` and `sarafu-async` save under `<sessionId>` The `devtools/admin/main.go` reads from the `<sessionId>.<sessionId>` resulting in an error when accessing account data created by `sarafu-at`

image.png

38 KiB

image.png

38 KiB

Alfred-mk commented

2025-02-20 13:06:35 +01:00

Author

Member

ea6bfa050e/db/db.go (L171)

For sarafu-at or sarafu-async, the sessionId is not set in the context (ctx). once the SetSession is called, the baseDb.sid is set to an empty byte, leading to a final sessionKey of just <sessionId>

When the same SetSession is called on sarafu-cmd or the admin devtool, the sessionId exists in the context.
This sets the baseDb.sid to <sessionId>., leading to a final sessionKey of <sessionId>.<sessionId>

Removing the sessionId from the ctx in the devtool/admin/main.go and cmd/main.go resolves the issue

https://github.com/nolash/go-vise/blob/ea6bfa050eebeb782d7cc49dabce637aa821c7ba/db/db.go#L171 For `sarafu-at` or `sarafu-async`, the sessionId is not set in the context (ctx). once the SetSession is called, the baseDb.sid is set to an empty byte, leading to a final sessionKey of just `<sessionId>` When the same `SetSession` is called on `sarafu-cmd` or the `admin devtool`, the sessionId exists in the context. This sets the baseDb.sid to `<sessionId>.`, leading to a final sessionKey of `<sessionId>.<sessionId>` Removing the sessionId from the ctx in the `devtool/admin/main.go` and `cmd/main.go` resolves the issue

Alfred-mk referenced this issue

2025-02-20 13:12:03 +01:00

remove the sessionId from the ctx #25