Why is iModelDb.key random during BriefcaseDb.onOpened

[MichaelBelousov]

I would make a bug report but I don't think I'll do it justice, so leaving this here for posterity.

Why is there a random guid created here?

This later gets overwritten to some variant of `${iModelId}:${changeset.id}` (only in some iModels it seems but I haven't traced which atm because I have a workaround for my case and there are a lot of Db types)

In my case, I see it overwritten here.

The biggest problem with this, is when I have a listener on BriefcaseDb.onOpened, during which the opening process is ostensibly already complete, the key can be the random guid, and then it gets reset later before I then during an RPC call try to find some data I cached at onOpened time.

So why is it done this way? Am I missing something? Will this help anyone?
I'm just going to manually build the key myself in my onOpened handler.

[pmconne]

@paulius-valiunas #6847

[kabentley]

The key that is returned from opening an iModel is merely meant to be a token that can be used to uniquely identify the opened file across process boundaries (that's why it's called "key"). However, some applications wished to use the key to identify the file to users in user interfaces. We therefore made it possible to optionally supply a unique key yourself in SnapshotDbOpenArg (so there's no need to do that in onOpen).

[MichaelBelousov]

Ok I'll check if the desktop template is doing that for some reason.

What's problematic to me is that the event fires after the db is opened. So why does the key change after that?

I don't need the key to be the imodelId, i just want it to be stable for when I try to access data I cached during that event, for that db

[paulius-valiunas]

I was going to say basically the same - the key is supposed to be opaque, but it has become expected that it would match the iModel/changeset id in some cases. I would argue that in a cloud environment it's largely irrelevant, because with horizontal scaling there shouldn't be any requirement for a stable 1:1 session between a backend and a frontend, so we do use the iModel and changeset ids there. But for desktop workflows, it should just be an opaque string.

But more importantly, it's supposed to remain stable and never change. I'm not sure how that happens, I hope it's not related to my change that @pmconne mentioned.

[kabentley]

It would have been nice if the key were always random, so nobody would ever ascribe any meaning to it. For example, it can't be "iModelId" since you can open different checkpoints of the same iModel.

But, then we added a way for apps to supply it, then for some reason we made it a combination of iModelId and ChangesetIds for opening checkpoints. I assume #6847 was an attempt to make somebody's interpretation of "key" consistent.

If you're not the one supplying "opts", then I guess setting key in onOpen is all you can do.

[MichaelBelousov]

Still, couldn't the behavior be for the key in onOpened to not be mutable after that point? Is the key useless for caching data after the db has been opened, unless I supply a key myself so I'm sure changes to it will not be attempted?

[paulius-valiunas]

#6847 was a security patch to prevent people from punching through our authorization layer by providing an iModel they have access to in the URL, but putting a different key in the request body. If we want the key to be a truly opaque string in cloud backends, we need to have a way to replicate the mapping through all instances of a scalable backend running in the cloud.

[kabentley]

Ahh, thanks @paulius-valiunas. I now remember why we made it "predictable" for RPC. We wanted to make it possible to have multiple backends servicing the same checkpoint. For that they all have to use the same key.

I don't understand why #6847 though.

[paulius-valiunas]

The goal of #6847 was to converge on a single source of truth that would be used both by the authorization layer and RPC. It could have been either the key or the URL, but it was decided to use the URL because parsing the request body would be a performance killer if we had to do that in a reverse proxy or any other microservice.

[paulius-valiunas]

To be honest, I don't really remember why I added the part in SnapshotDb. I should have documented it better. Since it's not used in cloud scenarios, I think the change can be undone.