Context manager direct instantiation

[rebehe]

This is the more Firebase idiomatic way to address the "multiple context managers" issue and ultimately replaces the global singleton approach. This works because _registerComponent is a factory function and is guaranteed to be called once. When we save the RootSpanContextManager object reference on CrashlyticsService, all module callers of RootSpanContextManager will end up with the same instance.

[changeset-bot]

🦋 Changeset detected

Latest commit: 303a12a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@firebase/ai	Minor
firebase	Minor
@firebase/firestore	Minor
@firebase/auth	Minor
@firebase/analytics-interop-types	Patch
@firebase/analytics	Patch
@firebase/firestore-compat	Patch
@firebase/auth-compat	Patch
@firebase/analytics-compat	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces the new @firebase/crashlytics package for OpenTelemetry-based telemetry, adds TemplateChatSession and responseJsonSchema support to @firebase/ai while deprecating Imagen models, and implements streaming for @firebase/data-connect. The code review identified critical race conditions and error handling flaws in the ChatSessionBase promise chaining logic that could lead to inconsistent state or unusable sessions after failures. Additionally, feedback was provided regarding ignored request options, incomplete tool aggregation for function calling, type inconsistencies in the Crashlytics service, and a suggestion for safer error message handling in user-defined functions.

[gemini-code-assist]

There is a race condition when _sendMessage is called multiple times synchronously. Because this._sendPromise is awaited before being updated, multiple calls can pass the initial await (line 136) before the first one updates the promise (line 145). This leads to concurrent execution of turns and inconsistent history state. The promise should be updated synchronously to queue the next turn correctly, and the history update should be moved inside the then block to ensure atomicity.

[gemini-code-assist]

If a request fails and the promise rejects, all subsequent calls to sendMessage will be skipped because then() is not called on a rejected promise. The chain should include a .catch(() => {}) before the next .then() to ensure the session remains usable after an error.

[gemini-code-assist]

Similar to _sendMessage, _sendMessageStream has a race condition where multiple synchronous calls can lead to concurrent execution of turns. The promise chain should be updated synchronously without an initial await.

[gemini-code-assist]

The maxSequentialFunctionCalls option from singleRequestOptions should be considered here. It is currently ignored in favor of this.requestOptions.

[gemini-code-assist]

The logic only considers the first tool that contains functionDeclarations. If a model response contains function calls defined across multiple tools, automatic function calling will fail or be incomplete. Consider iterating over all tools and aggregating their function declarations.

[gemini-code-assist]

Accessing (e as Error).message is unsafe if the thrown value is not an Error object. Use a safer check.

Suggested change

	`Error in user-defined function "${functionDeclaration.name}": ${
	(e as Error).message
	}`
	`Error in user-defined function "${functionDeclaration.name}": ${
	e instanceof Error ? e.message : String(e)
	}`

[gemini-code-assist]

The tracingProvider is marked as nullable in the constructor, but it is defined as non-nullable in the CrashlyticsInternal interface in types.ts. This inconsistency can lead to runtime errors when internal APIs expect it to be present.