Fatal Exception: RLMException "Key not found" when accessing filtered Results

[hyouuu]

Goals

access filtered results normally

Expected Results

after calling filter on Results, the filtered results should be accessable

Actual Results

accessing any property on the filtered Results would crash the app with exception "Key not found"

Steps for others to Reproduce

e.g. use predicate type ==[c] "calendar" where type is a String property on the realm object, then call searchResults.count would cause crash for some users. Note that my app recently updated from Realm 4.3.0 to 5.4.7

Version of Realm and Tooling

Realm framework version: 5.4.7

Realm Object Server version: NA

Xcode version: 12.0.1

iOS/OSX version: Both iOS 13 & 14

Dependency manager + version: SPM

There's an issue on .NET which seems to be from the same cause, and one of the participants said the latest version also didn't fix for him: realm/realm-dotnet#2025

This is causing 10% of my users to experience crash and please help find the cause and make a fix asap

[jedelbo]

Seems like the issue realm/realm-dotnet#2025 has been soloved. What you experience here must be a different issue. I would like to know if the type property has a search index defined.

[hyouuu]

@jedelbo yes it's indexed:

    override public class func indexedProperties() -> [String] {
        return ["date", "meta", "type", "tags", "repeatRule"]
    }

[jedelbo]

I assume that you are not able to reproduce this problem in your own test setup, but would you be able to share a sample realm file with some typical data in it so I can get a better idea of what is going on? You can share it privately with me by sending it to [email protected].

[hyouuu]

@jedelbo Unfortunately I don't have access to users' realm file, and haven't been able to repro myself. Will simulate the upgrade path and see if can get a file.

Another crash that might be related to this - when searching ((type ==[c] "journal") AND (tags CONTAINS[c] "tag_study_ff741a"))

Crashed: Realm notification listener
0  App                          0x10541cb68 realm::StringNode<realm::EqualIns>::get_key(unsigned long) + 393360
1  App                          0x10541af34 realm::StringNodeEqualBase::find_first_local(unsigned long, unsigned long) + 386140
2  App                          0x10541ad50 realm::ParentNode::aggregate_local(realm::QueryStateBase*, unsigned long, unsigned long, unsigned long, realm::ArrayPayload*) + 385656
3  App                          0x1053c8b68 realm::Query::aggregate_internal(realm::ParentNode*, realm::QueryStateBase*, unsigned long, unsigned long, realm::ArrayPayload*) const + 49296
4  App                          0x1053cd310 realm::util::FunctionRef<bool (realm::Cluster const*)>::FunctionRef<realm::Query::find_all(realm::ConstTableView&, unsigned long, unsigned long, unsigned long) const::$_4&>(realm::Query::find_all(realm::ConstTableView&, unsigned long, unsigned long, unsigned long) const::$_4&)::'lambda'(void*, realm::Cluster const*)::__invoke(void*, realm::Cluster const*) + 67640
5  App                          0x1053c9318 realm::Query::find_all(realm::ConstTableView&, unsigned long, unsigned long, unsigned long) const + 51264
6  App                          0x10544673c realm::ConstTableView::do_sync() + 40800
7  App                          0x105211c28 realm::_impl::ResultsNotifier::run() + 4337540136
8  App                          0x10520bcc4 realm::_impl::RealmCoordinator::run_async_notifiers() + 4337515716
9  App                          0x10520b640 realm::_impl::RealmCoordinator::on_change() + 4337514048
10 App                          0x1051f8abc realm::_impl::ExternalCommitHelper::listen() + 4337437372
11 App                          0x1051f95f8 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, realm::_impl::ExternalCommitHelper::ExternalCommitHelper(realm::_impl::RealmCoordinator&)::$_0> >(void*) + 4337440248
12 libsystem_pthread.dylib        0x1a27db914 _pthread_start + 168
13 libsystem_pthread.dylib        0x1a27e39d4 thread_start + 8

In realm/realm-dotnet#2025 @tipa said there're some threading issues - might be related to the above?

Is there any way to downgrade to 4.x? Would 10.x help at all?

[jedelbo]

I don't think this is a threading issue. Unfortunately we don't have a way of downgrading to 4.x. 10.x would probably have the same issue. The query engine is very much the same. I am rather confident that we can fix this issue.

[hyouuu]

Great to hear you're confident on this! Do you also have clue on the above StringNode issue - is that from the same cause?

[jedelbo]

The last example you gave also included the type ==[c] "journal" clause, so if this is causing the problem, then this could explain that crash too.

[jedelbo]

Do you have a stacktrace of the original error?

[jedelbo]

Root cause probably found!

[hyouuu]

That's awesome thanks @jedelbo! In the meanwhile I did a try catch block and used manual filtering to mitigate the issue for users, and will try the newer version and report back when I release the next version