Ian Costanzo

> Does that only need to be enabled on the OrgBook (holder) side? Yes, just on the OrgBook side. The issuer is fine, no changes required. PS for my local...

Overall looks good. I had one minor comment (a duplicate line of code I think) and we could use some docs (at a minimum just add the description of this...

> * Added a middleware that checks the singleton and blocks traffic for the particular wallet if upgrade is in progress. Will this work in a scaled environment? I.e. should...

> I don't think the upgrade should take very long for any agents or subwallets as the DB changes are just removing and replacing records. ... as long as we're...

> As I understand it, the plan is that the controller is responsible for scaling down, then start back up and calling this endpoint during controller initialization before proceeding. So...

> @ianco @swcurran I'm removing the in memory singleton part of this, and instead using the wallet(DB) value in the middleware. I hadn't considered the scaled up, multi instance use...

Also regarding the "upgrade check" do we need to check each time we process a received message as well? I.e. if we receive a message and the respective wallet is...

Fixed a few problems with the BC Reg issuer (mainly dealing with how data is split between the 2 databases) and one problem with how companies are re-queued for processing....

One more issue fixed in BC Reg - https://github.com/bcgov/von-bc-registries-agent/pull/353 This affects a couple of the "missing relationships" in OrgBook, but there are a few others that look like data issues...

All of the known processing issues have been fixed, there are a few stragglers that I think are due to data issues (inconsistencies between COLIN and LEAR) and I'm following...