-
Notifications
You must be signed in to change notification settings - Fork 66
Add EphemeralBaseAccountProvider for isolated payment flows #188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
🟡 Heimdall Review Status
|
…o enable it Separates telemetry initialization from global initialization so that: - First SDK call with telemetry: false doesn't prevent later calls from enabling telemetry - Telemetry is only loaded when at least one SDK instance requests it
fan-zhang-sv
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm i think there might still be some issues with this approach.
i wonder if we could
- switch to dependency injection, so we inject
storeupon creating sdk instance - and have ephemeral sdk use its own store instance upon creation
- and have ephemeral sdk removing this instance store upon clear()
- this way, there might be a chance we dont need to duplicate Provider/Signer code (not 100% sure)
|
|
||
| async handshake(args: RequestArguments) { | ||
| const correlationId = correlationIds.get(args); | ||
| logHandshakeStarted({ method: args.method, correlationId }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add an additional param isEphemeral to measure success for each component?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added!
| */ | ||
| export class EphemeralSigner { | ||
| private readonly communicator: Communicator; | ||
| private readonly keyManager: SCWKeyManager; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm i think keyManager could still be an issue
- keyManager is still reading and writing to global state in localStorage
- keyManager.clear() rotate the global key pair, which may intervene with concurrent operation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call. Added createStoreInstance() that can create either persistent (localStorage) or ephemeral (in-memory) store instances.
Now Signer/EphemeralSigner: Both accept a storeInstance parameter and pass it down to KeyManager
What changed? Why?
Adds
EphemeralBaseAccountProviderandEphemeralSignerfor single-use payment flows (pay()andsubscribe()).Problem: When multiple payment flows execute concurrently or sequentially, they share global state which causes race conditions and cleanup of one flow affects others.
Solution:
EphemeralBaseAccountProvider: Provider with isolated state that only supports payment methods (wallet_sendCalls,wallet_sign,wallet_getCallsStatus)EphemeralSigner: Signer that maintains instance-local state and cleans up without affecting global storesdkManager.tsto prevent concurrent payment operations from interferingcreateBaseAccountSDK.tsto avoid redundant setup callsSigner.cleanup()to preservestore.chainssince chain clients are shared infrastructureHow was this tested?
Existing test coverage for
createBaseAccountSDK.test.tsupdated to reset global initialization state between tests.How can reviewers manually test these changes?
pay()orsubscribe()multiple times in sequenceDemo/screenshots