-
Notifications
You must be signed in to change notification settings - Fork 236
feat(core): support multiple indy ledgers #474
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(core): support multiple indy ledgers #474
Conversation
Signed-off-by: Timo Glastra <timo@animo.id>
packages/core/src/modules/ledger/__tests__/IndyPoolService.test.ts
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #474 +/- ##
==========================================
+ Coverage 85.79% 86.39% +0.60%
==========================================
Files 254 266 +12
Lines 5525 5726 +201
Branches 892 920 +28
==========================================
+ Hits 4740 4947 +207
+ Misses 784 778 -6
Partials 1 1
Continue to review full report at Codecov.
|
@TimoGlastra I like the approach since multiple ledger pools are mainly needed mostly in POC and development phases. |
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 just have some minor points, but overall it seems good to me. Is multi-ledger-support added in any other framework as described in the document?
Also, this might be worth mentioning in the feature list, it is a very nice feature.
Things to add:
|
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>
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 looks great @TimoGlastra! I left minor requests.. and I think there may have been some tweaks still required from the last AFJ call?
packages/core/src/modules/ledger/__tests__/IndyPoolService.test.ts
Outdated
Show resolved
Hide resolved
import { LedgerError } from '../error/LedgerError' | ||
import { LedgerNotConfiguredError } from '../error/LedgerNotConfiguredError' | ||
import { LedgerNotFoundError } from '../error/LedgerNotFoundError' |
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.
Could we place all the errors within one file? It seems like it's a little more overhead/verbose to have them separate for less value from my POV?
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.
Sure. I'll do it in a follow up PR to keep consistency.In the rest of the codebase all errors have their own file
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.
Awesome 🔥
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Resolved feedback from AFJ call and PR. Ready for final review |
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.
Again, great work here, I appreciate the efforts put into this!
docs/getting-started/0-agent.md
Outdated
- `indyLedgers`: The indy ledgers to connect to. This is an array of objects with the following properties. Either `genesisPath` or `genesisTransactions` must be set, but not both. | ||
- `id`\*: The id (or name) of the ledger, also used as the pool name | ||
- `isProduction`\*: Whether the ledger is a production ledger. This is used by the pool selector algorithm to know which ledger to use for certain interactions (i.e. prefer production ledgers over non-production ledgers) | ||
- `genesisPath`: The path to the genesis file to use for connecting to an Indy ledger. | ||
- `genesisTransactions`: String of genesis transactions to use for connecting to an Indy ledger. |
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.
Potentially something important to highlight here would be that the order of the ledgers in the array determines their priority (after production vs non-production)? As indicated in a comment in the IndyPoolService:
We take the first value as we take the order in the indyLedgers config as
the order of preference of ledgers
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.
Yes great point. I'll update it
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 some documentation around ledgers
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Signed-off-by: Timo Glastra <timo@animo.id>
Adds support for using multiple indy ledgers simultaneously. I'd really like some input on the approach before wrapping up and merging.
genesisPath
,poolName
andgenesisTransactions
in theInitConfig
are replaced by theindyLedgers
array property with the following structure: (@MosCD3)Before each read operation in
IndyLedgerService
a new method is called,IndyPoolService.getPoolForDid
. The method will, if successful, return the pool that should be used for the operation. The process is a follows:remaining
groupremaining
group.remaining
group, return the pool associated with the responseremaining
responses and check for each if the did is self certifying.remaning
group based ontxnTime
. The pool associated with the earliesttxnTime
will be returned.@swcurran @shaangill025 I'm not so sure on 6. in the process. From the google document I understand that the txnTime is not the same as the time the DID was registered. In the HackMD document from @shaangill025 (https://hackmd.io/BVye073CTiqgNEMXxDeVdQ) the following step is described: "return production ledger with oldest/min datetime". Where does the oldest/min datetime property come from? I'd rather not have a service that tracks DIDs that are on multiple ledgers, and would be inclined to just throw an error instead that the DID couldn't be resolved.