No nodes available for a long time after refresh

[raineorshine]

Platform: Chrome
Thoughtspace: 1m
Fully replicated

On load, it continues to say "No nodes available" after the console says it is fully synced and ready for interaction.

• The status says "Disconnected • Initial sync done".
• The root node appears after 40–45 seconds.
• "Disconnected" changes to "Connected" after 2–3 minutes.

[TIME TO REPLICATION; FULL] Took 84.5ms.
[TIME TO REPLICATION; PARTIAL] Took 105.69999998807907ms.
[TIME TO INTERACTION] Took 280ms.
[FOREGROUND] Took 920.3999999761581ms.

[raineorshine]

@obezzad I'm still seeing this issue. Have you encountered this?

[obezzad]

This one is partially solved. It shares similar reasons with #7 (see #7 (comment)), thus the same optimization does speed up the tree rendering after the full sync is done and registered (i.e. must see "Initial sync done" as shown below).

The issue still persist when the data is synced but we still have "Pending initial sync", I believe the main reason is that partial sync is write-heavy slowing down all queries (confirmed on our custom diagnostics app), causing the read queries to slow down. I'm unsure what write operations are happening at the end of full sync, probably to ensure data integrity of all buckets before triggering the statusChanged internally. What I'm sure about is that we're noticing two related issues after progressing on this one (#2):

1. Queries are very slow during partial sync but they still happen decently fast.
2. They get way slower on the transitional phase between partial and full sync (before they become near-instant if we don't face NoModificationAllowedError: Failed to execute 'createSyncAccessHandle' on 'FileSystemFileHandle' #3).

One mitigation path for 1 is to sync and pre-load more data speculatively to memory (e.g. up to grandchildren) so the user can still navigate fast while the slightly slow queries (~1s) pre-load the next actions. I've already experimented with this in the early days of this project, reverted it due to the trade-off between time till interaction and navigation speed as partial sync was rigid, but the new prioritized sync makes it straightforward to sync direct children first (ensuring low TTI), grandchildren second (making navigation faster on partial sync), then the rest.

I'm still investigating (2) for a clear solution at our level without read concurrency or skipping ; already monitoring all queries execution to see what's happening.