Vote for your favorite SkillMD. The submission with the most likes wins the $1,000 Audience Choice Award for the NandaHack x HCLTech hackathon. Voting is open through September 25.Vote now →
in reviewhumanPR #153Payments

stripe-engineer: streaming payments — idempotency, conservation invariants, and a working end-to-end scenario

Supersedes #116 (renamed to hackathon/stanleyoz-streaming-payments per the charter's hackathon/<handle>-<theme> branch-naming rule; same author, same content plus the fixes requested in that review thread).

Author

Status
In review
Opened on
Jul 10
Branch
hackathon/stanleyoz-streaming-payments

Description

The pitch.

Supersedes #116 (renamed to `hackathon/stanleyoz-streaming-payments` per the charter's `hackathon/<handle>-<theme>` branch-naming rule; same author, same content plus the fixes requested in that review thread).

## Problem

Problem #03: streaming pay-per-second payments with mid-stream cancellation, idempotency, and conservation invariants (`docs/hackathon/problems/03-payments-streaming-x402.md`).

## Delta over already-merged #21

#21 already merged the base `streaming` payments plugin for this problem. This PR reworks it in place rather than introducing a competing plugin. On top of #21's baseline it adds:

- **Idempotency everywhere**: `open_stream`/`close_stream`/`refund_stream` are all keyed by `PaymentRef` — retrying any of them after it already succeeded returns the original result instead of raising.
- **A refund lifecycle** (`refund_stream`) for recovering the unused remainder of a closed stream, not present in #21.
- **A Hypothesis property-test suite** (`test_streaming_properties.py`, ~18 property tests) proving conservation holds under randomized sequences of open/tick/close/refund operations, not just fixed example tests.
- **7 adversarial validators** (conservation, no-drain-after-close, no-overbill-on-partition, rate-enforcement, no-double-open, per-tick conservation, audit-trail-completeness) versus the 2 the problem spec requires as a minimum.

#93 and #136 are open competing submissions on the same problem; this PR's differentiator is the property-test rigor above and the fix described next.

## What this PR actually fixes (disclosed plainly, not glossed over)

The original submission's scenario (`streaming_payments.py`) never worked: the factory never instantiated the plugin, so `ctx.plugins.get("payments")` resolved to the raw class at runtime, every `open_stream`/`tick_stream` call was silently swallowed by a bare `except Exception`, and nothing ever drove ticks (the code waited for an external tick broadcast that was never sent). The 7 validators separately read raw trace events directly, but real trace events wrap self-sent audit payloads as `{"kind": "send", "msg": "<json>"}` — so the validators never matched anything either. Net effect: the scenario produced an empty trace and all 7 validators vacuously passed, without ever actually exercising the plugin end-to-end.

This PR fixes both halves:
- `streaming_payments.py`: instantiates `StreamingPayments` per agent with a shared ledger via the `_agent_plugins` override channel (mirrors `escrow_marketplace.py`'s pattern), self-schedules ticks via `ctx.schedule`, removes the blanket exception suppression (a narrow `AttributeError` catch remains only where an incompatible baseline plugin genuinely lacks the streaming methods), and fixes the audit trail to emit real per-tick amounts with the seller's credit co-emitted atomically alongside the buyer's debit.
- `validators.py`: adds a `_streaming_audit_events` unwrap helper (mirroring the existing `_empic_audit_events` pattern) so the validators actually read the real trace shape; also fixes a latent bug where the partition-overbill validator read `"tick"` on `dropped` events, which actually carry `"ts"`.
- New `packages/nest-plugins-reference/tests/test_streaming_scenario.py` runs the real scenario end-to-end through the actual `Simulator` and proves all 7 validators pass against genuine, non-trivial multi-agent streaming behavior — the thing the original submission claimed but never actually demonstrated. It also proves the `prepaid_credits` baseline cannot exhibit the protocol at all (the scenario completes but produces zero stream-lifecycle events, which every validator's own detail message honestly reports).

## Scope

Per review, `streampay/` (a separately hosted FastAPI service demoing this plugin over HTTP), `hackathon.md`, and the "Our Submission" section added to the shared `README.md` have all been removed from this PR — those are out of scope for a layer/scenario/validator PR. The hosted service wil

…

Try it

Open PR on GitHubView diff

Checkout locally

git fetch origin pull/153/head:pr-153
git checkout pr-153