Migrating from 10.33.0 to 10.34.0 can no longer cast to MigrationObject.

[dlbuckley]

How frequently does the bug occur?

Always

Description

Overview

We are looking to migrate from version 10.33.0 to the latest version (10.37.1 at the time of writing) but our tests flagged up an issue affecting migration. It appears we can no longer cast to MigrationObject/DynamicObject which worked previously. Here is the migration code with added print statements to illustrate what is going wrong:

m.enumerateObjects(ofType: Subscription.className()) { (old, new) in

    guard let old, let new else { return }

    if let oldAccount = old["account"] as? DynamicObject {
        print("Old account: \(oldAccount)")
        if let accountId = oldAccount["id"] as? String {
            print("Account ID: \(accountId)")
            new["accountID"] = accountId // 10.33.0 successfully migrates the value
        } else {
            print("Failed to get account ID")
        }
    } else {
         print("Failed to get old account") // 10.34.0+ fails at this point instead of casting correctly
    }
}

In 10.33.0 we are able to cast old["account"] to a DynamicObject or MigrationObject and access it's subscript properties without issue. But as of 10.34.0 (I've tested all versions up to the latest and 10.34.0 was where the issue was introduced) the cast fails. I can't see anything within the release notes which would indicate a change in this behaviour.

Details

What seems to have worked (on 10.34.0+) is casting to RLMDynamicObject in the console. At this point I can then access the subscript properties with no issue. Unfortunately this is only possible in the console due to RLMDynamicObject being private.

But if I try to cast to either DynamicObject or MigrationObject I get nil.

The Subscription object is quite large, but you can see that account is clearly associated to it in this small snippet.

Stacktrace & log output

No response

Can you reproduce the bug?

Always

Reproduction Steps

The actual code this relates to is sensitive so I've shared what I can publicly for now.

Version

10.34.0

What Atlas Services are you using?

Local Database only

Are you using encryption?

No

Platform OS and version(s)

All

Build environment

Xcode version: 14.2
Dependency manager and version: SPM

[tgoyne]

How are you initializing your Realm instance that's performing the migration? The type of the objects passed to the migration callbacks is an internal configuration parameter set to MigrationObject when we convert a Realm.Configuration to the underlying RLMRealmConfiguration and to RLMMigrationObject when a RLMRealmConfiguration is created directly. It's possible that maybe one of our initialization paths is failing to propagate that value to the correct place?

[dlbuckley]

let config = Realm.Configuration(
    fileURL: containerURL,
    schemaVersion: schemaVersion,
    migrationBlock: realmMigration
)
Realm.Configuration.defaultConfiguration = config

I should note that the above migration is one of many migration steps over a number of different versions. They all pass their tests except for this one. (realmMigration is a closure thats declared elsewhere and passed in)

[tgoyne]

And then you're just doing try Realm() to trigger the migration?

[tgoyne]

Oh, I think I see what the problem is. -[RLMRealmConfiguration copy] isn't copying the migrationObjectClass property and opening via the default configuration involves a copy.

[dlbuckley]

Thanks for looking in to this for us, it sounds like there is a possible avenue to explore here? If you need us to test anything our side then please let us know and we would be happy to accommodate.

Just to note we are on GMT+1 so likely wont be able to look at any suggestions until tomorrow.

[dlbuckley]

@tgoyne I just pointed to the branch with the fix and it seems to have resolved our issue with the test which was failing 🎉 I'm just pushing it though our CI to make sure nothing else is broken and then will report back.

Thanks for the quick turn around on this issue!

[dlbuckley]

It looks like the branch fixes the issues we were seeing and hasn't introduced anything which were caught by our tests. Is it possible this can make it into a patch release or will we have to wait for the next minor release?

[dianaafanador3]

This was released on version v10.37.2