-
Notifications
You must be signed in to change notification settings - Fork 200
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
feat: break out indy wallet, better indy handling #396
feat: break out indy wallet, better indy handling #396
Conversation
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Codecov Report
@@ Coverage Diff @@
## main #396 +/- ##
==========================================
- Coverage 86.64% 86.30% -0.34%
==========================================
Files 248 249 +1
Lines 5210 5256 +46
Branches 830 784 -46
==========================================
+ Hits 4514 4536 +22
- Misses 696 720 +24
Continue to review full report at Codecov.
|
Signed-off-by: Timo Glastra <timo@animo.id>
@@ -16,14 +17,6 @@ export class MessagePickupService { | |||
this.messageRepository = messageRepository | |||
} | |||
|
|||
public async batchPickup(inboundConnection: InboundConnection) { |
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.
Was the batchPickup message removed intentionally?
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.
It wasn't used because the RecipientModule
directly creates a batch pickup message. I choose to remove this method, but it's probably better to use the service method instead. Will update
public async getAll(recordClass: BaseRecordConstructor<T>): Promise<T[]> { | ||
const recordIterator = await this.wallet.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS) | ||
const recordIterator = this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS) |
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.
Is the search not async any more? Are we missing an await?
const recordIterator = this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS) | |
const recordIterator = await this.search(recordClass.type, {}, IndyStorageService.DEFAULT_QUERY_OPTIONS) |
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.
this.search
returns a generator, which we can use as an async iterator. So the this.search
call itself is not async
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.
Some minor things. Nothing about the functionality but more I think some overlooked things.
Great changes! Love the errors :-)
packages/core/src/modules/connections/__tests__/ConnectionService.test.ts
Show resolved
Hide resolved
await this.create(walletConfig, walletCredentials) | ||
await this.open(walletConfig, walletCredentials) | ||
await this.create(walletConfig) | ||
await this.open(walletConfig) | ||
} else { | ||
throw error |
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.
Should this not be an AriesFrameworkError
or IndySdkError
?
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.
this.open
already handles this, so we'll always get an aries framework error here
public async verify(signerVerkey: string, data: Buffer, signature: Buffer): Promise<boolean> { | ||
try { | ||
// check signature | ||
const isValid = await this.indy.cryptoVerify(signerVerkey, data, signature) |
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.
Same here.
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.
I think in this case isValid
adds some useful context to what cryptoVerify
(and verify()
) returns
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
@jakubkoci could you please take a look at this PR? The slow review process is really slowing me down |
|
||
import { AriesFrameworkError } from './AriesFrameworkError' | ||
|
||
export class IndySdkError extends AriesFrameworkError { |
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.
This is kind of interesting. I would assume that IndySdk
is lower-level detail than framework level error. Therefore, I'm not sure about IndySdkError
extending AriesFrameworkError
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.
The normal IndyError
is lower-level detail than the framework level error. However, because the normal error is not very nice in stacktracing/information we've wrapped it with a framework specific error.
To me AriesFrameworkError
is the basis for all framework created errors (which is the case if we wrap the original error). I think it can be beneficial to have a single base error that allows to catch all framework errors. Maybe AriesFrameworkError is not the best name as the base error
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Extracts part of the code in #360.
Main reasons for this are:
I want to make a browser compatible wallet (already have a working one locally) so we can use the agent in the browser
Break out indy wallet
Fixes #330
It didn't make a lot of sense to me that the indy wallet was handling indy storage and ledger stuff. I think it belongs more in the ledger and storage services. This is also more in line with where we're headed with the shared components libraries
LedgerService
toIndyLedgerService
. It's very indy focussed now.IndyStorageService
IndyLedgerService
Better indy message handling
Sometimes you would get very cryptic errors such as
CommonInvalidParam
without a stack trace or anything that would help you get a sense of what's erroring out. I've wrapped all indy calls with a try catch and added a newIndySdkError
. This will take the indy error as input, but with very nice stack tracing so you know exactly where things went wrong, without losing information from the indy error