Skip to content

Fix notetaking Responses samples losing notes on new hosted sessions - #1039

Merged
Hui Miao (huimiu) merged 1 commit into
microsoft-foundry:mainfrom
JeffreyCA:fix/notetaking-responses-session-id
Oct 13, 2026
Merged

Hui Miao (huimiu) merged 1 commit into
microsoft-foundry:mainfrom
JeffreyCA:fix/notetaking-responses-session-id

Conversation

@JeffreyCA

Copy link
Copy Markdown
Contributor

Fixes #1038

This PR fixes the Python and C# notetaking Responses samples so notes saved on a fresh hosted session land in that session instead of a shared "default" file.

Issue

azd ai agent invoke --new-session doesn't send agent_session_id in the request body for hosted agents. The platform creates the session and returns its ID in the x-agent-session-id header, and azd saves that ID for the next invoke. Both handlers only read the body field, though, so that first call wrote to notes_default.jsonl.

The next invoke sends the real session ID, so get_notes reads notes_<id>.jsonl and comes back empty. Invokes that already had a session ID worked, which is why the bug only shows up after --new-session.

This isn't an azd regression. azd has left the body field empty for new remote sessions since /invocations support was added. The Python agentserver SDK resolves the session ID as the body field, then FOUNDRY_AGENT_SESSION_ID, then a derived value. The samples skipped the middle step. The .NET SDK reads the same variable.

Fix

Both handlers now resolve the session ID in this order:

  • agent_session_id from the request body, used by local runs and explicit callers
  • FOUNDRY_AGENT_SESSION_ID, set by the platform in hosted containers
  • "default", kept for local curl calls that pass no session

Local behaviour doesn't change, because azd ai agent invoke --local always sends a session ID in the body.

Notes still aren't shared across sessions. Each hosted session has its own sandbox and $HOME, so a note saved in one session won't show up after a second --new-session. That part of the report is by design.

Testing

When a hosted invoke omits agent_session_id from the request body, fall
back to the platform-supplied FOUNDRY_AGENT_SESSION_ID before the shared
"default" key, so notes are keyed to the session that actually runs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 5669b012-ea21-4939-93f9-ea72266b7852
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

Both implementations correctly address the missing request-body session ID while preserving local behavior.

0 open findings

What changed in this PR

Fixes note persistence for newly created hosted sessions by using the platform-provided session ID fallback.

Changes:

  • Resolves session IDs from request body, environment, then "default".
  • Applies equivalent behavior to Python and C# samples.
File Description
main.py Adds hosted-session environment fallback.
Program.cs Adds equivalent C# fallback and helper.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@huimiu
Hui Miao (huimiu) merged commit 10383e1 into microsoft-foundry:main Oct 13, 2026
35 of 39 checks passed

This branch had an error being deployed

1 failed deployment
L4-validation — 314644a8 Deployed Oct 13, 2026 by JeffreyCA via trusted #405
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Note-Taking Agent does not invoke tools when starting a new session in remote

3 participants