Skip to content

[Bug]: In-memory push store keeps the caller object so later mutations rewrite stored webhooks #1215

Closed as not planned
Bug
#1218
Closed as not planned
[Bug]: In-memory push store keeps the caller object so later mutations rewrite stored webhooks#1215
Bug
#1218
Assignees
rohityan
Labels
component: serverIssues related to frameworks for agent execution, HTTP/event handling, database persistence logic.status:awaiting responsestatus:stale

Description

@anxkhn
anxkhn
opened on Aug 27, 2026

What happened?

InMemoryPushNotificationConfigStore.set_info appends the caller proto and get_info / get_info_for_dispatch return those same objects.

After create/get, changing url/token/id on the request or response proto silently changes the stored webhook. The next send_notification POSTs to the mutated URL.

DatabasePushNotificationConfigStore already CopyFroms. InMemoryTaskStore wraps CopyingTaskStoreAdapter for the same reason. The JS SDK had this class of bug and cloned on save.

Repro

cfg = TaskPushNotificationConfig(url="http://a.example/cb")
await store.set_info("t1", cfg, ctx)
cfg.url = "http://evil.example/cb"
got = await store.get_info("t1", ctx)

Observed: got[0].url == "http://evil.example/cb"
Expected: stored copy still "http://a.example/cb"

Relevant log output

n/a.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

  1. rohityan
    self-assigned this
    on Aug 28, 2026
  2. rohityan
    added the
    Bug
    issue type on Aug 28, 2026

  3. rohityan commented on Aug 31, 2026

    @rohityan
    rohityan
    on Aug 31, 2026

    Hi @anxkhn , Thanks for reporting this and for opening the PR to fix it!
    The root cause seems to be that InMemoryPushNotificationConfigStore.set_info() stores the raw TaskPushNotificationConfig reference directly rather than performing a defensive copy. Because get_info() and get_info_for_dispatch() also return this reference directly, any in-place mutations on the caller's config object propagate into the in-memory store and affect subsequent notification dispatches.
    Until your PR is reviewed , you can work around this by explicitly cloning the protobuf / config object before passing it to set_info() or mutating it downstream.
    Assigning the issue to you till the PR gets reviewed.

  4. rohityan
    added
    component: serverIssues related to frameworks for agent execution, HTTP/event handling, database persistence logic.
    status:awaiting response
    on Aug 31, 2026

  5. github-actions commented on Sep 14, 2026

    @github-actions
    github-actionsbot
    on Sep 14, 2026 – with GitHub Actions

    Marking this issue as stale since it has been open for 14 days with no activity. This issue will be closed if no further activity occurs.

  6. github-actions
    added
    status:stale
    on Sep 14, 2026

  7. github-actions commented on Sep 27, 2026

    @github-actions
    github-actionsbot
    on Sep 27, 2026 – with GitHub Actions

    This issue was closed because it has been inactive for 27 days. Please post a new issue if you need further assistance. Thanks!

  8. github-actions
    closed this as not plannedon Sep 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

component: serverIssues related to frameworks for agent execution, HTTP/event handling, database persistence logic.status:awaiting responsestatus:stale

Type

Bug

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions