[anxkhn]

Description

• Follow the CONTRIBUTING Guide
• Conventional Commits title
• Tests and linter pass
• Docs updated if necessary

Fixes #1215

Summary

InMemoryPushNotificationConfigStore.set_info appended the caller proto. get_info and get_info_for_dispatch returned those same objects.

After create or get, changing url, token, or id on the request or response proto silently changed the stored webhook. The next notification POST went to the mutated URL.

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

set_info now CopyFroms into a new proto before assign-id and append. get_info and get_info_for_dispatch return copies. Default id assignment stays on the stored copy, not the caller.

Testing

Added test_set_info_copies_caller_and_returned_config.

uv run pytest tests/server/tasks/test_inmemory_push_notifications.py -q

21 passed.

[github-actions]

🧪 Code Coverage (vs main)

⬇️ Download Full Report

No coverage changes.

Generated by coverage-comment.yml

[mykytanetipa]

this leads to spec violation for on_create_task_push_notification_config (3.1.7: "Outputs: - TaskPushNotificationConfig: Created configuration with assigned ID")

on_create_task_push_notification_config is expected to set id for TaskPushNotificationConfig response if not provided by caller.

[mykytanetipa]

stored.id? notification_config.id can now be empty

[mykytanetipa]

Consider using _copy_config for consistency

[ConnorMoss02]

Simulated this locally against #1236's tests. On its own it makes the in-memory store return a config with no id, because the copy means the id lands on the store's object instead of the one the handler returns. All four of those tests fail without #1236 and pass with it.