feat(a2a-nats): add server push_set handler - #352
Conversation
yordis
commented
Jun 19, 2026
- Per-op slice of the server dispatch: webhook registration is the first push lifecycle entry point agents need. Delivery-semantics extension wiring (registry tracking, deliverySemantics field) is its own concern and lands separately.
Webhook registration is the first push lifecycle entry point agents need; the delivery-semantics extension wiring (registry tracking, deliverySemantics field) is its own concern and lands separately so this slice stays on the minimal unary template. Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
PR SummaryMedium Risk Overview
Registry tracking and Reviewed by Cursor Bugbot for commit 00a0410. Bugbot is set up for automated code reviews on this repo. Configure here. |
|
Warning Review limit reached
More reviews will be available in 51 minutes and 37 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughAdds a Changespush_notification_set handler for A2A NATS server
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Coverage SummaryDetailsDiff against mainResults for commit: 00a0410 Minimum allowed coverage is ♻️ This comment has been updated with latest results |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@rsworkspace/crates/a2a-nats/src/server/handler.rs`:
- Around line 118-121: The push_notification_set method signature needs to
separate boundary types from domain types. Replace the parameter and return type
from a2a::types::TaskPushNotificationConfig (the wire/boundary type) with a
corresponding domain type that represents the validated, internal
representation. If a domain type does not exist yet, create one that
encapsulates the validated configuration. The conversion from the boundary type
to the domain type should happen exactly once at the boundary entry point
(likely in a wrapper or adapter), ensuring that the trait method itself only
works with trusted domain types rather than untrusted wire types.
In `@rsworkspace/crates/a2a-nats/src/server/push_set.rs`:
- Around line 28-34: The current error handling in the match statement for
parse_request always returns error code -32700 for any parse failure, but this
should only be used for malformed JSON. Capture the actual error from
parse_request instead of using the _ pattern, then differentiate between true
JSON parse errors (return -32700) and invalid params shape errors (return
-32602). This ensures clients receive the correct JSON-RPC error code based on
whether the JSON itself is malformed or just contains an invalid params
structure.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f6655d99-4fda-410b-8a10-9a5975207597
📒 Files selected for processing (4)
rsworkspace/crates/a2a-nats/src/server/handler.rsrsworkspace/crates/a2a-nats/src/server/mod.rsrsworkspace/crates/a2a-nats/src/server/push_set.rsrsworkspace/crates/a2a-nats/src/server/test_support.rs
A well-formed JSON envelope with the wrong params shape is an Invalid params (-32602) failure, not a Parse error (-32700); conflating them gives clients the wrong JSON-RPC failure class. Sibling per-op handlers share the same pattern and follow in a separate cleanup PR. Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>