bug(@langchain/google) Non-standard property `originalTextContentBlock` on `AIMessageChunk` output from `.stream()` `ChatGoogle` invoke, is ignored when constructing Gemini API request body.

[vjancik]

Checked other resources

• This is a bug, not a usage question. For questions, please use the LangChain Forum (https://forum.langchain.com/).
• I added a very descriptive title to this issue.
• I searched the LangChain.js documentation with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.
• I am sure that this is a bug in LangChain.js rather than my code.
• The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code

Refer to .json files attached to this issue #10561

Error Message and Stack Trace (if applicable)

No response

Description

Using .stream() with ChatGoogle and optionally .concat(), the individual chunks have an additional_kwargs property of originalTextContentBlock that is serialized together with the equivalent text content in content. (Doubling the serialized size in the process).
This happens on both outputFormat v0 and v1.

I couldn't find any consumers of this property, or reference to any explanation in upstream Gemini API docs:

https://www.google.com/search?q=gemini+api+%22originalTextContentBlock%22
https://www.google.com/search?q=langchain+%22originalTextContentBlock%22
https://github.com/search?q=repo%3Alangchain-ai%2Flangchainjs%20originalTextContentBlock&type=code

Therefore, there are only two possible reasons in my mind. Either this property is an unused legacy property from previous iterations of the google provider library, or this property is entirely hallucinated by AI and should be removed.

System Info

Package: @langchain/google
Version: 0.1.9
Companion: @langchain/core 1.1.37 (peerDependency enforced)
Runtime: bun 1.3.11
Platform: Ubuntu 25.10 (Linux 6.17.0-14-generic)

[pawel-twardziak]

hi Viktor Jančík (@vjancik)

thanks for this detailed description of the issue.

I dug through @langchain/google@0.1.9 and this does not look hallucinated or dead. It is real provider-specific metadata, and there are active consumers for it in the LangChain.js codebase.

First, the field is explicitly created in the Google provider when a Gemini candidate is converted into a LangChain AIMessage. When LangChain decides a response is "just one text block", it collapses content down to a plain string for convenience, but still preserves the original Gemini block in additional_kwargs.originalTextContentBlock. That preserved block is not only text - it can also carry Gemini-specific metadata like thoughtSignature and partMetadata. See:

• convertGeminiPartToContentBlock()
• convertGeminiCandidateToAIMessage()

Second, there are real readers for the field:

• For non-v1 Google/provider-native messages, the Google content-block translator uses it when message.content is a string, so message.contentBlocks can reconstruct the richer Google block instead of only { type: "text", text }.
• For true output_version: "v1" messages, contentBlocks is read directly from content, so the translator is bypassed - however, the field can still matter later if the message is converted back to Gemini parts.
• During streaming with thinking models, it is also used to merge a thoughtSignature back into the final non-thinking text block when that signature arrived in a metadata-only chunk.
• When LangChain converts an AIMessage back into Gemini parts, it prefers message.additional_kwargs.originalTextContentBlock over the lossy normalized block.

Relevant code:

• ChatGoogleTranslator
• contentBlocks short-circuits to content for output_version: "v1" in AIMessage and AIMessageChunk
• Outbound conversion back to Gemini parts: message.additional_kwargs.originalTextContentBlock || block
• Streaming path keeps carrying it and even rewrites its .text after chunk concatenation: ChatGoogle._generate() and _streamResponseChunks() and stream chunk construction
• There are dedicated tests for this behavior in core: google.test.ts

So the answer to "is this unused legacy state or hallucinated?" is: no. In 0.1.9, it is intentional compatibility metadata used to preserve Gemini-specific information after LangChain normalizes content.

That said, I do think your serialization-size complaint is valid.

LangChain’s message model allows:

• raw content to be either a string or provider-native blocks
• contentBlocks to be lazily reconstructed into a standard shape
• provider-specific metadata to live alongside the message

The official docs describe that split: raw content can be a string or provider-native blocks, while contentBlocks is the standardized representation, and outputVersion: "v1" only opts into storing standard content blocks in content - it does not promise that provider-specific metadata in additional_kwargs will disappear. See:

• Messages docs
• Models docs

So it makes sense that you still see the field in both v0 and v1.

My take is:

1. The field should probably not be removed outright, because that would risk breaking Google reasoning/streaming fidelity and round-tripping back into Gemini.
2. But it probably should not be serialized so noisily when it is fully redundant with content.

The cleanest fix would be:

• keep originalTextContentBlock internally for Google-specific reconstruction/round-tripping
• omit it from serialized output when it contains nothing beyond the same plain text already present in content
• keep it only when it carries extra provider metadata such as thoughtSignature or partMetadata

There is also a strong reason to be conservative here: in the related issue #10561, you show a case where AIMessageChunk.concat() is wrong after the first non-text chunk, while originalTextContentBlock still reflects the correct text block. So today, this field is not just extra baggage - in at least one known edge case it is also the more faithful representation.

Practical workaround

If your application is only logging or persisting model output and does not need Google-specific round-tripping, you can strip the field from a serialized copy after you are done with .concat(), contentBlocks, and any Gemini re-use. I would not mutate the live AIMessageChunk, because AIMessageChunk.concat() merges additional_kwargs, so deleting the field early can change later merged results.

function compactSerializedChunk(chunk: any) {
  const serialized = chunk.toJSON();
  const block = serialized?.kwargs?.additional_kwargs?.originalTextContentBlock;
  const content = serialized?.kwargs?.content;

  if (block && typeof content === "string" && typeof block.text === "string") {
    const metadataKeys = Object.keys(block).filter((key) => key !== "text");
    if (block.text === content && metadataKeys.length === 0) {
      delete serialized.kwargs.additional_kwargs.originalTextContentBlock;
    }
  }

  return serialized;
}

If you need preserved Gemini metadata like thoughtSignature or partMetadata, do not strip it.

Sources

• Issue: langchain-ai/langchainjs#10562
• Related issue: langchain-ai/langchainjs#10561
• LangChain JS docs: Messages, Models
• LangChain.js source at local commit 6b914bceb4acd4664b12091770a2ddcbf5d8457e:
  • libs/providers/langchain-google/src/converters/messages.ts
  • libs/providers/langchain-google/src/chat_models/base.ts
  • libs/langchain-core/src/messages/ai.ts
  • libs/langchain-core/src/messages/block_translators/google.ts
  • libs/langchain-core/src/messages/block_translators/tests/google.test.ts
  • libs/langchain-core/src/load/serializable.ts

[vjancik]

Strange, not sure why my search didn't pick those up. Yes I see now that there are multiple uses for those additional fields.

Still, it remains that there are two sources of truth for the same "text" field, one in standard cross-provider content: form, and one in the originalTextContentBlock. I don't see how these could or would diverge, right now they are one to one. And therefore one of them is redundant.

I wonder, in the case of gemini-code-execution-2026-03-31T13-32-46-251Z-v0-stream-collected.json
how is the discrepancy actually resolved when using the AIMessageChunk as input to ChatGoogle. How can the originalTextContentBlock > .text be used as-is, with those non-text blocks in-between? Does it go in the beginning? Or in the end? Either way it will Not be the original ordering of text -> non-text -> text chunks, if it's used as the source of truth for text content.

So my case stands, that having two sources of "text" will lead to unpredictable behavior and divergence across providers. additional_kwargs should only hold actually additional properties.

I will add the Gemini API fetch request transformed body for that serialized file example output later, to see how it behaves.

[vjancik]

Ok, so it is dropping the thoughtSignature altogether. I am not sure if this is a new bug or a regression. It's using the content: and ignoring the originalTextContentBlock

Script:

/**
 * Dev script that loads a collected AIMessageChunk from a prior stream run,
 * reconstructs it, and re-sends it as history to ChatGoogle — intercepting the
 * generateContent request to log the serialized body without making a real API call.
 *
 * Run: bunx cross-env AGENT=1 bun run scripts/dev/gemini-code-execution-resend.ts
 */

import { AIMessageChunk, HumanMessage } from "@langchain/core/messages";
import { ChatGoogle } from "@langchain/google/node";

const COLLECTED_PATH = `${import.meta.dir}/gemini-code-execution-2026-03-31T22-17-10-269Z-v0-stream-collected.json`;

// ---------------------------------------------------------------------------
// Fetch proxy — intercepts generateContent, logs request body, short-circuits
// ---------------------------------------------------------------------------

const originalFetch = globalThis.fetch;

globalThis.fetch = async function proxiedFetch(input: Request | string | URL, init?: RequestInit): Promise<Response> {
    const url = input instanceof Request ? input.url : String(input);

    if (url.includes("generateContent")) {
        let body: unknown = "(unreadable)";
        try {
            const rawBody = init?.body ?? (input instanceof Request ? await input.clone().text() : undefined);
            if (typeof rawBody === "string") {
                body = JSON.parse(rawBody);
            } else if (rawBody instanceof Uint8Array || rawBody instanceof ArrayBuffer) {
                body = JSON.parse(new TextDecoder().decode(rawBody));
            } else {
                body = rawBody;
            }
        } catch {
            body = "(parse error)";
        }

        console.log(`[gemini-code-execution-resend] generateContent request body:\n${JSON.stringify(body, null, 2)}`);

        return new Response(JSON.stringify({ error: { message: "fake 500 from proxy", code: 500 } }), {
            status: 500,
            headers: { "Content-Type": "application/json" },
        });
    }

    return originalFetch(input, init);
} as typeof globalThis.fetch;

// ---------------------------------------------------------------------------
// Load, reconstruct, and resend
// ---------------------------------------------------------------------------

const parsed = JSON.parse(await Bun.file(COLLECTED_PATH).text()) as { kwargs: Record<string, unknown> };

const chunk = new AIMessageChunk(parsed.kwargs);

console.log(`[gemini-code-execution-resend] Loaded AIMessageChunk with ${Array.isArray(chunk.content) ? chunk.content.length : 1} content block(s)`);
console.log(`[gemini-code-execution-resend] additional_kwargs:\n${JSON.stringify(chunk.additional_kwargs, null, 2)}`);

const llm = new ChatGoogle({
    model: "gemini-3-flash-preview",
    apiKey: "FAKE_API_KEY",
});

try {
    await llm.invoke([new HumanMessage("Render the normal distribution of IQ scores into a graphic for me"), chunk, new HumanMessage("test")]);
} catch {
    // Expected — fake 500 causes an error; request body was already logged above
}

for gemini-code-execution-2026-03-31T13-32-46-251Z-v0-stream-collected.json:

bun ./scripts/dev/gemini-code-execution-resend.ts 
[gemini-code-execution-resend] Loaded AIMessageChunk with 11 content block(s)
[gemini-code-execution-resend] additional_kwargs:
{
  "originalTextContentBlock": {
    "type": "text",
    "text": "To render the normal distribution of IQ scores, we typically use a mean (μ) of 100 and a standard deviation (σ) of 15.\n\nHere's how the normal distribution for IQ scores looks:\n\n*   **Mean (μ):** 100\n*   **Standard Deviation (σ):** 15\n\nThe Probability Density Function (PDF) for a normal distribution is given by:\n`f(x) = (1 / (σ * sqrt(2 * π))) * exp(-((x - μ)^2) / (2 * σ^2))`\n\nLet's calculate the probability density at a few key points:\n\n*   **At the Mean (IQ = 100):** This is the peak of the curve.\n*   **One Standard Deviation from the Mean (IQ = 85 and IQ = 115):** Approximately 68% of people fall within this range.\n*   **Two Standard Deviations from the Mean (IQ = 70 and IQ = 130):** Approximately 95% of people fall within this range.\n*   **Three Standard Deviations from the Mean (IQ = 55 and IQ = 145):** Approximately 99.7% of people fall within this range.\n\nI will use Python to calculate these PDF values.\n\nThe table above shows the probability density at key IQ scores.\n\n**Summary of the Normal Distribution for IQ Scores:**\n\n*   **Shape:** It's a classic **bell curve**, perfectly symmetrical around its mean.\n*   **Center:** The peak of the curve is at **IQ 100**, which is the average IQ score. This is where the highest density of people is found.\n*   **Spread:** The scores are distributed such that:\n    *   Approximately **68.2%** of people have an IQ between 85 and 115 (within one standard deviation of the mean).\n    *   Approximately **95.4%** of people have an IQ between 70 and 130 (within two standard deviations of the mean).\n    *   Approximately **99.7%** of people have an IQ between 55 and 145 (within three standard deviations of the mean).\n*   **Tails:** The curve gradually tapers off towards the extreme ends (very low and very high IQs), indicating that such scores are much less common.\n*   **Total Probability:** The total area under the entire curve represents 1 (or 100%), meaning all possible IQ scores for the population are covered.\n\nThis distribution model helps in understanding the prevalence of different IQ scores within a population."
  },
  "finishReason": "STOP"
}
[gemini-code-execution-resend] generateContent request body:
{
  "generationConfig": {
    "candidateCount": 1
  },
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "Render the normal distribution of IQ scores into a graphic for me"
        }
      ]
    },
    {
      "role": "model",
      "parts": [
        {
          "text": "To render the normal distribution of IQ scores, we typically use a mean (μ) of 100 and a standard deviation (σ) of 15.\n\nHere's how the normal distribution for IQ scores looks:\n\n*   **Mean (μ):** 100\n*   **Standard Deviation (σ):** 15\n\nThe Probability Density Function (PDF) for a normal distribution is given by:\n`f(x) = (1 / (σ * sqrt(2 * π))) * exp(-((x - μ)^2) / (2 * σ^2))`\n\nLet's calculate the probability density at a few key points:\n\n*   **At the Mean (IQ = 100):** This is the peak of the curve.\n*   **One Standard Deviation from the Mean (IQ = 85 and IQ = 115):** Approximately 68% of people fall within this range.\n*   **Two Standard Deviations from the Mean (IQ = 70 and IQ = 130):** Approximately 95% of people fall within this range.\n*   **Three Standard Deviations from the Mean (IQ = 55 and IQ = 145):** Approximately 99.7% of people fall within this range.\n\nI will use Python to calculate these PDF values.\n\n"
        },
        {
          "type": "executableCode",
          "executableCode": {
            "language": "PYTHON",
            "code": "import numpy as np\nfrom scipy.stats import norm\n\n# Define parameters for IQ scores\nmu = 100  # Mean IQ\nsigma = 15 # Standard deviation of IQ\n\n# Define IQ values for which to calculate the PDF\niq_values = [mu, mu - sigma, mu + sigma, mu - 2*sigma, mu + 2*sigma, mu - 3*sigma, mu + 3*sigma]\niq_values.sort() # Sort for better presentation\n\nprint(f\"Mean (μ): {mu}\")\nprint(f\"Standard Deviation (σ): {sigma}\\n\")\n\nprint(\"IQ Score | Probability Density (PDF)\")\nprint(\"---------------------------------\")\nfor iq in iq_values:\n    pdf_value = norm.pdf(iq, loc=mu, scale=sigma)\n    print(f\"{iq:<9} | {pdf_value:.6f}\")\n\n# Describe the shape for a textual rendering\nprint(f\"\\nCharacteristics of the Normal Distribution for IQ Scores:\")\nprint(f\"- The curve is bell-shaped and symmetrical around the mean (IQ = {mu}).\")\nprint(f\"- The highest point of the curve is at the mean (IQ = {mu}), where the probability density is approximately {norm.pdf(mu, loc=mu, scale=sigma):.6f}.\")\nprint(f\"- The curve extends infinitely in both directions, but most of the area (and thus population) is concentrated within three standard deviations of the mean (roughly IQ {mu - 3*sigma} to {mu + 3*sigma}).\")\nprint(f\"- The total area under the curve is 1, representing 100% of the population.\")\n\n"
          }
        },
        {
          "type": "codeExecutionResult",
          "codeExecutionResult": {
            "outcome": "OUTCOME_OK",
            "output": "Mean (μ): 100\nStandard Deviation (σ): 15\n\nIQ Score | Probability Density (PDF)\n---------------------------------\n55        | 0.000295\n70        | 0.003599\n85        | 0.016131\n100       | 0.026596\n115       | 0.016131\n130       | 0.003599\n145       | 0.000295\n\nCharacteristics of the Normal Distribution for IQ Scores:\n- The curve is bell-shaped and symmetrical around the mean (IQ = 100).\n- The highest point of the curve is at the mean (IQ = 100), where the probability density is approximately 0.026596.\n- The curve extends infinitely in both directions, but most of the area (and thus population) is concentrated within three standard deviations of the mean (roughly IQ 55 to 145).\n- The total area under the curve is 1, representing 100% of the population.\n"
          }
        },
        {
          "text": "The table"
        },
        {
          "text": " above shows the probability density at key IQ scores.\n\n**Summary of the Normal Distribution for IQ"
        },
        {
          "text": " Scores:**\n\n*   **Shape:** It's a classic **bell curve**, perfectly symmetrical around its mean.\n*   **Center:** The peak of the curve is at **IQ 100**, which is the average IQ"
        },
        {
          "text": " score. This is where the highest density of people is found.\n*   **Spread:** The scores are distributed such that:\n    *   Approximately **68.2%** of people have an IQ between 85 and"
        },
        {
          "text": " 115 (within one standard deviation of the mean).\n    *   Approximately **95.4%** of people have an IQ between 70 and 130 (within two standard deviations of the mean).\n    "
        },
        {
          "text": "*   Approximately **99.7%** of people have an IQ between 55 and 145 (within three standard deviations of the mean).\n*   **Tails:** The curve gradually tapers off towards the extreme"
        },
        {
          "text": " ends (very low and very high IQs), indicating that such scores are much less common.\n*   **Total Probability:** The total area under the entire curve represents 1 (or 100%), meaning all possible IQ scores for"
        },
        {
          "text": " the population are covered.\n\nThis distribution model helps in understanding the prevalence of different IQ scores within a population."
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "text": "test"
        }
      ]
    }
  ]
}

and for gemini-code-execution-2026-03-31T22-17-10-269Z-v0-stream-collected.json:

bun ./scripts/dev/gemini-code-execution-resend.ts 
[gemini-code-execution-resend] Loaded AIMessageChunk with 1 content block(s)
[gemini-code-execution-resend] additional_kwargs:
{
  "originalTextContentBlock": {
    "type": "text",
    "text": "To visualize the normal distribution of IQ scores (also known as a **Bell Curve**), imagine a symmetrical hill where the center is the average and the tails represent the extremes.\n\nIn modern IQ testing (such as the WAIS-IV or Stanford-Binet), the distribution is calibrated with a **mean of 100** and a **standard deviation (SD) of 15**.\n\nHere is how that looks in a graphic layout:\n\n### The Bell Curve Visualization\n\n```text\n                                  100 (Mean)\n                                     /  \\\n                                    /    \\\n                                   /      \\\n                      (68% of Pop) /        \\ (68% of Pop)\n                                  /          \\\n              (13.5%)            /            \\            (13.5%)\n       ________/_____\\__________/              \\__________/_____\\________\n      /        |      \\         |                |         /      |        \\\n     /   2%    | 13.5% |  34%   |      34%       |  34%   | 13.5% |   2%    \\\n    /__________|_______|________|________________|________|_______|__________\\\n   70         85       100       115      130      145\n (-2 SD)    (-1 SD)   (Mean)   (+1 SD)   (+2 SD)   (+3 SD)\n```\n\n---\n\n### Breaking Down the Zones\n\nTo understand the graphic, read it in terms of \"Standard Deviations\" (SD). Because the total area under the curve is 100%, we can assign percentages to each section:\n\n1.  **The Center (100):** This is the average. About **50%** of the population scores above 100, and **50%** scores below 100.\n2.  **The \"Average\" Range (85–115):** This represents the space between -1 and +1 standard deviation. Roughly **68%** of the entire human population falls within this range.\n3.  **The \"Above/Below Average\" Range (70–85 and 115–130):** This captures the next **27%** of the population (13.5% on each side).\n4.  **The Extremes (Below 70 and Above 130):** These are the \"tails\" of the curve.\n    *   **Above 130:** Often classified as \"Gifted\" (about 2% of the population).\n    *   **Below 70:** Often classified as the threshold for \"Intellectual Disability\" (about 2% of the population).\n\n### Key Characteristics of this Graphic:\n*   **Symmetry:** The left side is a perfect mirror image of the right side.\n*   **Asymptotic Tails:** The curve gets closer and closer to the horizontal axis as it moves away from the center, but it never actually touches it. This represents the rare possibility of extremely high or low scores.\n*   **The \"Rule of 68-95-99.7\":**\n    *   **68%** of people fall within 1 SD of the mean (85–115).\n    *   **95%** of people fall within 2 SD of the mean (70–130).\n    *   **99.7%** of people fall within 3 SD of the mean (55–145).\n\n**Why does this matter?**\nThis distribution shows that \"extreme\" intelligence (either very high or very low) is mathematically rare. The vast majority of people are clustered toward the center of the bell.",
    "thoughtSignature": "EjQKMgG+Pvb7mCiGQZG4dVLZE603uDzCtN7cULhmAUkG8e0QCTPZK7C7QJA7t4FfwTExZiBj"
  },
  "finishReason": "STOP"
}
[gemini-code-execution-resend] generateContent request body:
{
  "generationConfig": {
    "candidateCount": 1
  },
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "Render the normal distribution of IQ scores into a graphic for me"
        }
      ]
    },
    {
      "role": "model",
      "parts": [
        {
          "text": "To visualize the normal distribution of IQ scores (also known as a **Bell Curve**), imagine a symmetrical hill where the center is the average and the tails represent the extremes.\n\nIn modern IQ testing (such as the WAIS-IV or Stanford-Binet), the distribution is calibrated with a **mean of 100** and a **standard deviation (SD) of 15**.\n\nHere is how that looks in a graphic layout:\n\n### The Bell Curve Visualization\n\n```text\n                                  100 (Mean)\n                                     /  \\\n                                    /    \\\n                                   /      \\\n                      (68% of Pop) /        \\ (68% of Pop)\n                                  /          \\\n              (13.5%)            /            \\            (13.5%)\n       ________/_____\\__________/              \\__________/_____\\________\n      /        |      \\         |                |         /      |        \\\n     /   2%    | 13.5% |  34%   |      34%       |  34%   | 13.5% |   2%    \\\n    /__________|_______|________|________________|________|_______|__________\\\n   70         85       100       115      130      145\n (-2 SD)    (-1 SD)   (Mean)   (+1 SD)   (+2 SD)   (+3 SD)\n```\n\n---\n\n### Breaking Down the Zones\n\nTo understand the graphic, read it in terms of \"Standard Deviations\" (SD). Because the total area under the curve is 100%, we can assign percentages to each section:\n\n1.  **The Center (100):** This is the average. About **50%** of the population scores above 100, and **50%** scores below 100.\n2.  **The \"Average\" Range (85–115):** This represents the space between -1 and +1 standard deviation. Roughly **68%** of the entire human population falls within this range.\n3.  **The \"Above/Below Average\" Range (70–85 and 115–130):** This captures the next **27%** of the population (13.5% on each side).\n4.  **The Extremes (Below 70 and Above 130):** These are the \"tails\" of the curve.\n    *   **Above 130:** Often classified as \"Gifted\" (about 2% of the population).\n    *   **Below 70:** Often classified as the threshold for \"Intellectual Disability\" (about 2% of the population).\n\n### Key Characteristics of this Graphic:\n*   **Symmetry:** The left side is a perfect mirror image of the right side.\n*   **Asymptotic Tails:** The curve gets closer and closer to the horizontal axis as it moves away from the center, but it never actually touches it. This represents the rare possibility of extremely high or low scores.\n*   **The \"Rule of 68-95-99.7\":**\n    *   **68%** of people fall within 1 SD of the mean (85–115).\n    *   **95%** of people fall within 2 SD of the mean (70–130).\n    *   **99.7%** of people fall within 3 SD of the mean (55–145).\n\n**Why does this matter?**\nThis distribution shows that \"extreme\" intelligence (either very high or very low) is mathematically rare. The vast majority of people are clustered toward the center of the bell."
        }
      ]
    },
    {
      "role": "user",
      "parts": [
        {
          "text": "test"
        }
      ]
    }
  ]
}

In the second example it clearly omits the thoughtSignature in originalTextContentBlock, so it's definitely a reconstruction bug.

[vjancik]

I wonder if it has something to do with the fact that some AIMessageChunks have thoughtSignature inlined in content: and some (text ones) don't.
Example:

{
  "lc": 1,
  "type": "constructor",
  "id": [
    "langchain_core",
    "messages",
    "AIMessageChunk"
  ],
  "kwargs": {
    "content": [
      {
        "thoughtSignature": "EjQKMgG+Pvb7qd8ISEI4uBa8JN5jcGVkT4zfZ6wQWHVn36FvYxN35ZgmfUYuQ91QJOCpMPNN",
        "type": "executableCode",
        "executableCode": {
          "language": "PYTHON",
          "code": "import numpy as np\nimport matplotlib.pyplot as plt\nimport scipy.stats as stats\n\n# Define the parameters for the IQ distribution\n# IQ is typically defined with a mean of 100 and a standard deviation of 15\nmu = 100\nsigma = 15\n\n# Create a range of IQ scores\nx = np.linspace(mu - 4*sigma, mu + 4*sigma, 1000)\ny = stats.norm.pdf(x, mu, sigma)\n\n# Create the plot\nplt.figure(figsize=(10, 6))\nplt.plot(x, y, color='blue', lw=2)\n\n# Shade areas for standard deviations\nx_fill = np.linspace(mu - 3*sigma, mu + 3*sigma, 1000)\ny_fill = stats.norm.pdf(x_fill, mu, sigma)\nplt.fill_between(x_fill, y_fill, color='skyblue', alpha=0.3)\n\n# Add vertical lines for mean and standard deviations\nplt.axvline(mu, color='black', linestyle='--', label='Mean (100)')\nfor i in range(1, 4):\n    plt.axvline(mu + i*sigma, color='gray', linestyle=':', alpha=0.5)\n    plt.axvline(mu - i*sigma, color='gray', linestyle=':', alpha=0.5)\n\n# Formatting\nplt.title('Normal Distribution of IQ Scores')\nplt.xlabel('IQ Score')\nplt.ylabel('Probability Density')\nplt.xticks(np.arange(mu - 4*sigma, mu + 5*sigma, sigma))\nplt.grid(axis='x', linestyle='--', alpha=0.3)\nplt.legend()\nplt.tight_layout()\n\n# Save the plot\nplt.savefig('iq_distribution.png')\nprint(\"Plot saved as iq_distribution.png\")\n",
          "id": "y4w08t6r"
        }
      },

Only the inlined ones get passed on according to this demonstration it seems.

[vjancik]

Ok so I resorted to a manual .concat() implementation until this gets fixed:

import { AIMessageChunk } from "@langchain/core/messages";

/** A content block as returned by @langchain/core — an open record with a `type` discriminant. */
type ContentBlock = Record<string, unknown> & { type: string };

/**
 * Normalizes a single chunk's content to an array of ContentBlock objects.
 *
 * When the upstream library produces a string-content chunk (e.g. a plain-text
 * streaming delta), it stores the original structured block in
 * `additional_kwargs.originalTextContentBlock`. We prefer that over a synthetic
 * `{ type: "text", text: "..." }` block so that `thoughtSignature` and other
 * metadata carried on the original block are preserved.
 *
 * Also exported so callers can normalize a single-chunk stream that never goes
 * through {@link concatMessageChunks}.
 */
export function normalizeContent(chunk: AIMessageChunk): ContentBlock[] {
    const original = chunk.additional_kwargs?.originalTextContentBlock;
    const hasOriginal = original !== null && original !== undefined && typeof original === "object";

    if (typeof chunk.content === "string") {
        if (hasOriginal) return [original as ContentBlock];
        return [{ type: "text", text: chunk.content }];
    }

    if (!Array.isArray(chunk.content)) {
        throw new Error(`concatMessageChunks: unexpected content type "${typeof chunk.content}"`);
    }

    // If originalTextContentBlock carries a thoughtSignature, stamp it onto the first
    // text block in the array — the array may have mixed block types so we iterate.
    const originalSignature = hasOriginal ? (original as ContentBlock).thoughtSignature : undefined;
    if (originalSignature !== undefined) {
        const blocks = chunk.content as ContentBlock[];
        const firstTextIndex = blocks.findIndex((b) => b.type === "text");
        if (firstTextIndex !== -1) {
            const patched = [...blocks];
            patched[firstTextIndex] = { ...patched[firstTextIndex], thoughtSignature: originalSignature } as ContentBlock;
            return patched;
        }
    }

    return chunk.content;
}

/**
 * Merges two normalized content arrays into one, coalescing adjacent text blocks.
 *
 * Two text blocks are merged (text concatenated) unless both carry a
 * `thoughtSignature` — in that case they are kept separate because each signature
 * corresponds to a distinct reasoning span and must not be conflated.
 */
function joinNormalizedContents(blocksA: ContentBlock[], blocksB: ContentBlock[]): ContentBlock[] {
    return [...blocksA, ...blocksB].reduce<ContentBlock[]>((acc, block) => {
        const prev = acc[acc.length - 1];

        if (
            prev?.type === "text" &&
            block.type === "text" &&
            // Keep separate if both already carry independent thought signatures
            !(prev.thoughtSignature !== undefined && block.thoughtSignature !== undefined)
        ) {
            // Merge: append text and carry the incoming thoughtSignature if present
            const merged: ContentBlock = {
                ...prev,
                text: String(prev.text ?? "") + String(block.text ?? ""),
            };
            if (block.thoughtSignature !== undefined) {
                merged.thoughtSignature = block.thoughtSignature;
            }
            acc[acc.length - 1] = merged;
            return acc;
        }

        acc.push(block);
        return acc;
    }, []);
}

/**
 * Concatenates two AIMessageChunks, fixing the upstream bug where text blocks
 * following a non-standard content block (e.g. executableCode, inlineData) are
 * not merged by the default `.concat()` implementation.
 *
 * All other chunk fields (tool_calls, usage_metadata, response_metadata, etc.)
 * are handled by the upstream `.concat()` — we only replace the content array.
 */
export function concatMessageChunks(chunkA: AIMessageChunk, chunkB: AIMessageChunk): AIMessageChunk {
    const upstream = chunkA.concat(chunkB);

    const mergedContent = joinNormalizedContents(normalizeContent(chunkA), normalizeContent(chunkB));

    return new AIMessageChunk({
        ...upstream.lc_kwargs,
        content: mergedContent,
    });
}

This fixes:

1. concat() not joining text blocks after non-text block.
2. It inlines thoughtSignature from originalTextContentBlock on plain string contents:, until it gets correctly picked up and transformed by the @langchain/google parts transformer.
3. It makes sure to emit text blocks as separate blocks if they both have thoughtSignatures already, to not lose any signatures.

So for now, all chunks out of .stream() have to go through this to behave correctly when used as input in later turns.

Note that this workaround relies on originalTextContentBlock containing full text: content, which may change in the future.

[afirstenberg]

I haven't dug through this or the PR yet, but I can explain why it was added in the first place.

Usually, the original parts are preserved as part of the "content" of the AIMessage.
However, for backwards compatibility, if the only part is a text part, then the "content" is a string.
In those cases, we needed some way to access the additional metadata (in particular, the thought signature) when sending the next request to the server. Which is why it was added as an additional attribute on the AIMessage.

Do we think this is related to one of the thought signature errors we're still seeing? If so, do we have a solid test case we can add to the integration tests?