Bug on nested array linking objects update, (bug not happening on Realm 12.2.1)

[angelos3lex]

How frequently does the bug occur?

Always

Description

So we have to update to RN 0.74.5 (from 0.72) and we were on 12.2.1 realm version. Unfortunately, keeping same realm version, makes the app block on white screen, and through logcat I can see it's just saying " Building an exports object", but never proceeds.
So, I tried with 12.12.1 and 12.13.1 realm versions, which do not have this problem and everything goes smoothly, except from one use case.

I have a parent object Participant which has a subTable array of ParticipantMeta objects. ParticipantMeta are linking objects to the parent Participant.

When i create a Participant object with some metas, it's correctly added on the db.
When i query it, and re-add it using realm.create with Realm.UpdateMode.ALL, without any change at all, the meta list array becomes empty.

I have created a reproducible "minimal" repo that you can see on the logs the problem.

Update to RN 0.74 is crucial as we need to target api 34, and be able to release on playstore. Currently, this is our only blocker.

Stacktrace & log output

no crash. Only from the logs we can see that before updating the object we have full array and after the update, the array of the subTable is emptied.

Can you reproduce the bug?

Always

Reproduction Steps

https://github.com/angelos3lex/Realm-js-12.13.1-bug-repro
Check this repo ^
(Mainly App.tsx onPress of the button is where the whole logic begins.)

PS: Didn't test the reproducible example on iOS, but on my real case app it's also happening on iOS.

Version

12.12.1, 12.13.1

What services are you using?

Local Database only

Are you using encryption?

No

Platform OS and version(s)

android, iOS, realm 12.12+, RN 0.74.5

Build environment

no debugger

Cocoapods version

didn't test the reproducible example on iOS, but on my real case app it's also happening on iOS.

[sync-by-unito]

➤ PM Bot commented:

Jira ticket: RJS-2903

[angelos3lex]

Bonus on above reproducible repo:
If you change realm version to 12.2.1, you will be able to reproduce the freezing white screen after metro loads. By logcat I can just see the following logs:

JSRealm                 com.realmbrokenproject               V  setDefaultRealmFileDirectory
JSRealm                 com.realmbrokenproject               D  Absolute path: /data/data/com.realmbrokenproject/files
JSRealm                 com.realmbrokenproject               V  install
JSRealm                 com.realmbrokenproject               V  Building an exports object

[angelos3lex]

Hello any news? I also updated the reproducible example by simplifying a lot some business logic so that it's only reproducible with simple Realm objects.

We are available for call or discussion on the subject. We need to release new version on store with targetApi34 and RN 0.74, but this is our only blocker at this point :(

[kraenhansen]

@angelos3lex thanks for reporting the bug and for reaching out (again). I tried looking into your reproduction repo, but there's a lot going on in there. The use of DAOs are not a pattern we've been promoting as it makes the code more indirect and add a lot of complexity that I'm having a hard time wrapping my head around TBO.

As you've hinted, a bug like this is likely not platform specific and to simplify things, making it easier for us to reproduce the bug and add a test for it, it would be great if you could reproduce it using a simple npm init && npm install realm@12 and have a single file, executed via node which opens the realm without the use of class-based models (if that's possible) and simply performs a write and a read, reproducing the bug. Alternatively, you could spend a bit more time removing stuff which is not realm specific from your repo and add a few comments, making it easier for us to understand what's going on 👍

Thanks a lot in advance!

[angelos3lex]

Hello @kraenhansen I just created a new branch with a really minimal example,
https://github.com/angelos3lex/Realm-js-12.13.1-bug-repro/tree/remove_RN_completely
There is no need for RN etc, just yarn and then yarn reproduce. All code exists in example.js file and i commented some parts.
Actual code starts at line 105, above are just class definitions

[kraenhansen]

That's a huge improvement! Thanks - I'll get back as I get to investigate this further.

[angelos3lex]

Hey @kraenhansen any advancements on the matter?

[angelos3lex]

Another comment on the subject:
If i clone the queried object, and then save it, then the update works flawlessly, and the bug is not reproduced.
Which seems like the problem is only when updating a managed object directly, without cloning it first..

[angelos3lex]

Hello @kraenhansen, kindly asking for any update on this. Or maybe we could help more from our side somehow?

[kraenhansen]

Havn't had time to investigate this.