[realppl 10] Add server timestamp support

[wu-hui]

No description provided.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

[google-oss-bot]

	1 Warning
⚠️	Did you forget to add a changelog entry? (Add #no-changelog to the PR description to silence this warning.)

Generated by 🚫 Danger

[cherylEnkidu]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds comprehensive support for handling server-generated timestamps within the Realtime Pipeline API. The changes span across the C++, Objective-C, and Swift layers, introducing the necessary logic to evaluate server timestamps based on the specified ServerTimestampBehavior (.estimate, .previous, or .none). The implementation is well-structured, propagating listen options down to the expression evaluation context. The inclusion of extensive integration and unit tests is excellent and covers the new functionality well.

I've found one potential bug in the Swift PipelineResult initializer that could lead to incorrect data types, and a minor typo in a test function name. Once these are addressed, the PR should be in great shape.

[gemini-code-assist]

The new initializer appears to be missing the conversion from Objective-C objects to Swift Sendable types for the data dictionary. The self.bridge.data(with: serverTimestamp) method returns an [String: Any] dictionary where the values are still Objective-C objects (like NSString, NSNumber). Without this conversion, consumers of the data property might encounter unexpected types at runtime.

The other initializer correctly uses .mapValues { Helper.convertObjCToSwift($0) } for this purpose, and the same should be applied here to ensure type consistency.

Suggested change

	init(_ bridge: __PipelineResultBridge, _ behavior: ServerTimestampBehavior) {
	self.bridge = bridge
	serverTimestamp = behavior
	ref = self.bridge.reference
	id = self.bridge.documentID
	data = self.bridge.data(with: serverTimestamp)
	createTime = self.bridge.create_time
	updateTime = self.bridge.update_time
	}
	init(_ bridge: __PipelineResultBridge, _ behavior: ServerTimestampBehavior) {
	self.bridge = bridge
	serverTimestamp = behavior
	ref = self.bridge.reference
	id = self.bridge.documentID
	data = self.bridge.data(with: serverTimestamp).mapValues { Helper.convertObjCToSwift($0) }
	createTime = self.bridge.create_time
	updateTime = self.bridge.update_time
	}

[cherylEnkidu]

+1

[gemini-code-assist]

There's a typo in the function name. It should be testSamePipelineWithDifferentOptions.

Suggested change

	func testSamePipelineWithDifferetnOptions() async throws {
	func testSamePipelineWithDifferentOptions() async throws {

[cherylEnkidu]

+1

[cherylEnkidu]

why the const is removed here?