Access profile on plugin initialization

[TimoGlastra]

We're currently writing a plugin for ACA-Py that needs access to the profile and storage on startup and having a hard time finding a clean approach to this. The setup method only takes the InjectionContext, no profile, and the routes registration also doesn't get a profile.

How we currently solved is by adding a new endpoint and then calling that from the setup method. This is not ideal but gives us access to the context.

I was thinking whether we could maybe add an event that will be emitted after the agent has fully started. This would allow us to hook into that from the setup method and have access to the profile. Bonus is that we don't have to guess anymore when ACA-Py is fully initialized because the event will only trigger after the agent is initialized.

Is it already possible to do this? If not do you think something like the event I described above would work? Are there other (better) solutions?

[TimoGlastra]

cc @dbluhm. You know a lot about plugins and event busses :)

[dbluhm]

We've run into this as well. The few times we've needed a profile, we've ended up restructuring things and getting the profile through another event or similar but I agree that having both "startup" and "shutdown" events would be beneficial.

[ianco]

I agree, startup and shutdown events would be beneficial.

I recently added a facility for protocols to subscribe to events (part of the endorser refactor work), you can check out the schema, cred def and revocation protocols for an example (e.g. https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/messaging/credential_definitions/routes.py#L422)

... so using this, a protocol could listen for startup and shutdown events, and it would be pretty straightforward to add these event notifications ...

[ianco]

I suggest we add a "provision" event as well. aca-py provision can be used for example to create the initial wallet database, there are probably other setup type operations that should be done on provision vs start

[dbluhm]

I fumbled the reopening of this issue (sorry) but while I've already triggered notifications: do we want to track the provision event addition as a feature request within this issue and keep it open until implemented?

[swcurran]

Do we think the provision event needs to handled in the same way? If so, please add a new issue.

Closing this one as complete as originally requested.