Changesets applied after iModel open don't always work

[tcobbs-bentley]

Describe the bug
When I download the first version of an iModel (which in this case I think is empty), then open the iModel, then pull changesets, I get an empty view. If I close the iModel and reopen it after pulling the changesets, it displays as expected. This implies to me that the view isn't properly handling the updates that were applied by the changesets.

To Reproduce
Steps to reproduce the behavior:

1. Use NativeApp.requestDownloadBriefcase with asOf set to NativeVersion.first() and opts.syncMode set to SyncMode.PullAndPush.
2. Open the the downloaded briefcase.
3. Use pullChanges on the briefcase to update it to the latest version.
4. Display the open iModel in a viewport.

Expected behavior
The iModel should display, including the latest changes present in the latest changeset.

Desktop (please complete the applicable information):

• OS: iOS
• Browser iOS WebView
• Version 18.1.1
• iTwin.js Version 4.10.3

Additional context
If I close the iMode after calling pullChanges and then reopen it, everything displays fine. The sequence above was performed on a local build of the iTwin Mobile SDK sample app. However, I have no reason to believe that this is a mobile-only bug. I will be pushing the changes that allow for this sequence shortly. I can provide information about the specific iModel I am using upon request.

Note: if I update the UserLabel on a specific element and push those changes on one device, then open the previously downloaded briefcase and pull changes, the UserLabel updates do immediately appear in the view. So some changes clearly do show up immediately without having the close and reopen the iModel.

[nick4598]

Sounds similar to https://github.com/iTwin/itwinjs-backlog/issues/1321, except that they explicitly call a fxn meant to refresh the viewport IModelApp.viewManager.refreshForModifiedModels. I haven't gotten a chance to dive deep into the issue I linked yet, but I do wonder if it would be possible to setup an integration test for this. The only problem is I'm not yet sure how to compare tiles before and after pulling changes. Maybe something like this:

1. Update geometry stream of an element A in a changeset C
2. Have a briefcase before changeset C
3. Generate the tile for element A
4. pull changeset C
5. Generate the tile for element A again
6. Compare the two tiles asserting they're different (but we might fail because they're the same?)

Is it possible to easily do steps 3 and 5? I don't really know what it looks like in code to "generate a tile for element A" or whether that even makes sense. @markschlosseratbentley do you know?

[markschlosseratbentley]

I don't really know what it looks like in code to "generate a tile for element A" or whether that even makes sense. @markschlosseratbentley do you know?

Tiles are generated based on the view.
It would most likely be easiest to generate all tiles for a scene with only one tile.
Then you could compare that one tile for any changes.

[nick4598]

Tiles are generated based on the view. It would most likely be easiest to generate all tiles for a scene with only one tile. Then you could compare that one tile for any changes.

What would the relevant APIs be to achieve that? Does that mean I absolutely need a view (making the test impossible to write? or maybe just harder to write?)

[markschlosseratbentley]

@nick4598 Actually, this test might be a good example of loading and checking a single tile (the root tile of a tree):

itwinjs-core/full-stack-tests/core/src/frontend/standalone/tile/TileIO.test.ts

Line 649 in c031ba2

it("should obtain a single leaf tile", async () => {