Thoughtspace powered by treecrdt

[Antonov548]

No description provided.

[raineorshine]

@karunkop Can you help investigate why the BrowserStack caret test is failing in this PR? I suggest manually confirming the test case in the app to confirm whether it's a test issue or regression.

[raineorshine]

Hi! Thanks for all the great work. There was a lot to wire up. I'm glad to see so many of the tests intact.

I haven't done any manual testing yet, but I reviewed all the code and figured we would start there.

General observations:

• I will leave the contents of /src/data-providers mostly up to you. You can own that like you own the internal treecrdt code. I'll focus on the interface with the front-end.
• The wait logic to the puppeteer tests is a bit heavy-handed, but I think is safe to include in the initial merge and optimize later.
• Some test changes are more invasive and add tight coupling between the tests and the application logic which is undesirable. I've added comments at specific instances below. These are probably blockers since merging them now and then trying to clean them up later is going to be messy. There are some basic encapsulation boundaries that need to be respected to preserve code quality. Hopefully we can figure out the test environment quirks so we don't need the backdoors.
• On main, all db interaction must go through the data-provider interface. This PR lacks a similar abstraction boundary, and exposes a variety of functions directly to different parts of the app (though mostly to initialize). Some of these can probably be hidden within the db provider's internal init function, while others may require front-end changes. Let's discuss what the proper abstraction boundary should be. Here are the treecrdt functions that I noticed were exposed directly to the front-end:
  • db
  • dropTreeCrdt
  • enqueueMaterializedThoughtsToStore
  • initPermissionsStore
  • initTreeCrdt
  • isTreecrdtLocalMaterialization
  • pushTreecrdtLocalOptsToRemote
  • registerTreecrdtClose
  • tryStartTreecrdtWebSocketSyncFromEnv
  • tsid, tsidShared, clientIdReady
  • waitForTreecrdtWriteBarrier
  • writeBarrier

[marcus-pousette]

Managed to reproduce D on my end too still now by driving my phone with the scenario (the emulator was not enough). Continuing the investigation

[marcus-pousette]

Seems to be a Webkit memory leak bug with Asyncify with iOS 26, using synchronous wa-sqlite seem to fix it. Upstream fix in progress cybersemics/treecrdt#237 . I tried a build from this and the app ran without hiccups after that

[marcus-pousette]

@BayuAri which version of iOS are you running? after updating my phone this morning I have a hard time to reproduce this failure (I am now running 26.6). Previously I tested on 26.3, and I see an outstanding. bug report for memory leak for 26.4 so I suspect everthing <= 26.4 is affected at least

[BayuAri]

@marcus-pousette
I am using iPhone 14 PM on iOS 26.5.2

[marcus-pousette]

@BayuAri thanks for info then 26.5 might be affected too. Please try again now with the new changes without updating your phone to a newer iOS. These fixed it for me before on 26.3

[BayuAri]

@marcus-pousette
Issue D is confirmed fixed on iOS Capacitor but the issue is still reproducible on Mobile Safari.
Tested on iPhone 14 PM iOS 26.5.2

The loading is quite laggy on Mobile Safari.
Tested on 157 thoughts and 153 descendants

Issue.D.on.iOS.Capacitor.vs.Mobile.Safari.-.s.mov

[marcus-pousette]

@BayuAri thanks for the report. I did not reproduce your issue exactly, testing on two different phones, however I monitored RAM and CPU usage and I think there is a memory leak upstream #4969 that I observe scrolling deep trees, that could explain the reload/flake you observe.

@raineorshine please review this PR when you have time

[raineorshine]

#4969 is fixed and merged.

@BayuAri Can you test Issue D on Mobile Safari again? Thanks!

[BayuAri]

@raineorshine
Issue D is no longer reproducible on Mobile Safari.
It works smoothly now.
Tested on iPhone 14PM iOS 26.5.2 and 16e iOS 26.6