Fix reading the local database state just after the initial write

[laevandus]

🔗 Issue Links

Resolves PBE-5519

🎯 Goal

• Enable reading the local database state within synchronize()'s completion block when the initial DB state was empty

📝 Summary

• Remove the additional OperationQueue from the BackgroundDatabaseObserver (less latency)
• Process DB changes immediately on the managed context queue (less latency)
• Fix an issue where the initial observer state was set to empty although data was just written to the DB
• Fix a timing issue with will change callback what returned changed data (timing related)

🛠 Implementation

BackgroundDatabaseObserver tries to load the initial state as soon as observing starts using a background thread (less blocking of the main thread). Since it is an async operation, there is a data race between loading the initial state and the managed object context changing at the same time. For avoiding it, the observer keeps an internal state to figure out when it can use the cached items array. This internal state was incorrect if the DB was empty and there just was a DB write as well. The observer's implementation is similar to the StateLayerDatabaseObserver now where we use NSManagedObjectContext's thread for processing and accessing the state (better data consistency).

Account Chewbacca in the demo app:

// ComposerVC.swift:925
    quotedMessageId: content.quotingMessage?.id,
    skipEnrichUrl: content.skipEnrichUrl,
    extraData: content.extraData
  )
  test()
}

func test() {
  guard let chatClient = channelController?.client else { return }
  let identifier = ChannelId(type: .messaging, id: "D65B357E-8")
  let query = ChannelQuery(cid: identifier, pageSize: 20)
  let channelController = chatClient.channelController(for: query)
        
  channelController.synchronize { error in
    if let error {
        log.error("Failed to get messages: \(error)")
        return
     }
     // The last 20 messages should be in channelController.messages
     let messages = channelController.messages
     print(messages.count)
  }
}

🧪 Manual Testing Notes

Account: Chewbacca

1. Paste that snippet to somewhere which gets triggered after connecting (I used ComposerVC.swift line 925 to call this snippet, this is triggered when sending a message)
2. Logout and login with Chewbacca
3. Send a message which triggers the snippet
4. Observe the message count, it should return 20 (checking console log, best is to put a breakpoint after the print)

Exploratory testing (because DB observers affect all the controllers)

☑️ Contributor Checklist

• I have signed the Stream CLA (required)
• This change should be manually QAed
• Changelog is updated with client-facing changes
• Changelog is updated with new localization keys
• New code is covered by unit tests
• Comparison screenshots added for visual changes
• Affected documentation updated (docusaurus, tutorial, CMS)

[Stream-SDK-Bot]

SDK Size

title	develop	branch	diff	status
StreamChat	6.73MB	6.73MB	0.0MB	🟢
StreamChatUI	4.41MB	4.41MB	0.0MB	🟢

[laevandus]

Because data is accessible as soon as startObserving is called, I removed the will change delegate because it does not really make sense anymore (we allow immediate access). I kept the didChange because we still do async loading.

[Stream-SDK-Bot]

SDK Performance

target	metric	benchmark	branch	performance	status
MessageList	Hitches total duration	10 ms	0.0 ms	100.0% 🔼	🟢
	Duration	2.6 s	2.56 s	1.54% 🔼	🟢
	Hitch time ratio	4 ms per s	0.0 ms per s	100.0% 🔼	🟢
	Frame rate	75 fps	78.18 fps	4.24% 🔼	🟢
	Number of hitches	1	0.0	100.0% 🔼	🟢
ChannelList	Hitches total duration	12.5 ms	27.53 ms	-120.24% 🔽	🔴
	Duration	2.6 s	2.54 s	2.31% 🔼	🟢
	Hitch time ratio	5 ms per s	10.83 ms per s	-116.6% 🔽	🔴
	Frame rate	72 fps	73.89 fps	2.63% 🔼	🟢
	Number of hitches	1.2	2.4	-100.0% 🔽	🔴

[Stream-SDK-Bot]

SDK Size

title	develop	branch	diff	status
StreamChat	6.76 MB	6.75 MB	-18 KB	🚀
StreamChatUI	4.41 MB	4.41 MB	0 KB	🟢

[nuno-vieira]

Code Wise looks good. But we need to make sure the benchmark passes and also we should do some smoke testing CC @testableapple

[martinmitrevski]

Looks good ✅ Please check the failed performance benchmarks before merging

[sonarqubecloud]

Quality Gate passed

Issues
152 New issues
0 Accepted issues

Measures
0 Security Hotspots
84.4% Coverage on New Code
0.1% Duplication on New Code

See analysis details on SonarCloud

[laevandus]

Manually triggered performance job here