Skip to content

ask_question.py can capture stale NotebookLM responses instead of the newly generated answer #25

@renanwilliam

Description

@renanwilliam

Problem

ask_question.py can return the wrong NotebookLM answer when the notebook already contains prior conversation history and/or the new answer takes time to hydrate.

In my case, the CLI kept returning the generic notebook intro:

Esse é o notebook com as possibilidades de integração com SOC...

But the browser UI had already produced the correct, much longer answer.

Reproduction

  1. Open a notebook with existing chat history.
  2. Ask a new question with python scripts/run.py ask_question.py --question "..." --notebook-url "...".
  3. Use a notebook with many sources and a slower response path.
  4. Observe that the script can return a stale/older message instead of the newly generated answer shown in the UI.

Root cause

The current polling logic in scripts/ask_question.py:

  • snapshots only the latest visible response element
  • assumes elements[-1] is the newest completed answer
  • does not distinguish previously hydrated responses from the current answer
  • can treat transient NotebookLM placeholders like Reading through pages... / Finding key words... as part of the response lifecycle
  • uses a fixed 120s timeout, which is tight for notebooks with many sources

Because NotebookLM chat history may hydrate asynchronously, the last response element after submit is not always the new answer. The script can therefore stabilize on an older response.

Proposed fix

I validated a local fix with these changes:

  1. Wait briefly for existing responses to hydrate before submitting the new question.
  2. Snapshot all existing assistant responses before asking.
  3. During polling, scan responses from newest to oldest and select the newest candidate that:
    • is not the user question
    • is not a known transient placeholder
    • was not already present before submission
  4. Keep the stability check for the selected candidate.
  5. Increase QUERY_TIMEOUT_SECONDS from 120 to 300.

Result

After applying the fix locally, the same notebook/query returned the correct employee export list instead of the stale intro message.

If useful, I already have a patch ready and can open a PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions