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

[anxkhn]

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

[rohityan]

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.