grassrootseconomics/sarafu-vise
8
0
Fork 0
Code Issues 15 Pull Requests 4 Actions Packages Projects Releases Wiki Activity

Executables not accessing the same state #23

New Issue
Closed
opened 2025-02-19 11:37:53 +01:00 by Alfred-mk · 3 comments
Alfred-mk commented 2025-02-19 11:37:53 +01:00
Member
Copy Link

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
Copy Link

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

image

What sarafu-cmd creates

image

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
Copy Link

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 commented 2025-02-21 09:19:09 +01:00
Author
Member
Copy Link

Resolved by PR #25

Resolved by PR #25
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ussd/user-reported
Issue reported by a user while interacting with the ussd
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
The priority is critical
Priority
High
The priority is high
Priority
Low
The priority is low
Priority
Medium
The priority is medium
Reviewed
Confirmed
Issue has been confirmed
Reviewed
Duplicate
This issue or pull request already exists
Reviewed
Invalid
Invalid issue
Reviewed
Won't Fix
This issue won't be fixed
Status
Abandoned
Somebody has started to work on this but abandoned work
Status
Blocked
Something is blocking this issue or pull request
Status
Need More Info
Feedback is required to reproduce issue or to continue work
No Label Kind/Bug
Priority
Critical
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Alfred-mk amina carlos kamikazechaser lash mango-habanero williamluke willruddick
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: grassrootseconomics/sarafu-vise#23
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?