Add Been proof-of-existence to demos - #16
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 24 minutes and 41 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThis PR introduces the "Been" semantic logging pattern across multiple demo applications. New Context classes (ReceiptGeneratedContext, OrderFinalizedContext, UserCreatedContext) are added to capture domain events. Final classes inject Been, record events via Changes
Sequence DiagramsequenceDiagram
participant Test as Test/Client
participant Final as Final<br/>(e.g., ContactReceived)
participant Been as Been<br/>(SemanticLogger)
participant Context as Context<br/>(e.g., ReceiptGeneratedContext)
Test->>Final: Construct with #[Inject] Been $been
Final->>Been: Receive injected Been instance
Final->>Context: Create new Context(data)
Context-->>Final: Return Context instance
Final->>Been: Record via with(context)
Been-->>Final: Return Been with recorded event
Final->>Final: Assert events[0] instanceof Context
Final->>Final: Assert context properties match
Test->>Final: Access $final->been->events
Test->>Test: Verify causal chain proven
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
demos/user-registration/src/Final/UserRegistered.php (1)
45-47: Make the proof check resilient to pre-existing events.Reading
$this->been->events[0]assumes the first event is the one just recorded. If the chain already has events, this can assert against the wrong element.♻️ Suggested patch
- $event = $this->been->events[0]; + $events = $this->been->events; + $event = $events[array_key_last($events)] ?? null; assert($event instanceof UserCreatedContext); assert($event->email === $this->email, 'User must be created with the input email');🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@demos/user-registration/src/Final/UserRegistered.php` around lines 45 - 47, The current check reads $this->been->events[0] which assumes the new UserCreatedContext is the first event; make the proof resilient by locating the actual UserCreatedContext that matches the test email instead of indexing [0]. In the test surrounding $this->been->events and assertions, search through $this->been->events for an instance of UserCreatedContext with ->email === $this->email (or take the last event if you intend "most recent"), then assert that such an event was found and that its email equals $this->email; update references to $event accordingly so the assertion no longer depends on a fixed index.demos/contact-form/src/Final/ContactReceived.php (1)
42-44: Use a stable event selection for the assertion proof.Indexing
events[0]can validate the wrong event when the chain is already populated; prefer checking the last appended event.♻️ Suggested patch
- $event = $this->been->events[0]; + $events = $this->been->events; + $event = $events[array_key_last($events)] ?? null; assert($event instanceof ReceiptGeneratedContext); assert($event->email === $this->normalizedEmail, 'Receipt must be for the normalized email');🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@demos/contact-form/src/Final/ContactReceived.php` around lines 42 - 44, The assertion currently grabs $this->been->events[0] which can be wrong for non-empty chains; instead select the last appended event (e.g. use array_key_last($this->been->events) or count()-1) and assign it to $event, then assert $event instanceof ReceiptGeneratedContext and $event->email === $this->normalizedEmail as before; update the code around the $event assignment to use $this->been->events[array_key_last($this->been->events)] (or equivalent) rather than events[0].
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@demos/contact-form/src/Final/ContactReceived.php`:
- Around line 42-44: The assertion currently grabs $this->been->events[0] which
can be wrong for non-empty chains; instead select the last appended event (e.g.
use array_key_last($this->been->events) or count()-1) and assign it to $event,
then assert $event instanceof ReceiptGeneratedContext and $event->email ===
$this->normalizedEmail as before; update the code around the $event assignment
to use $this->been->events[array_key_last($this->been->events)] (or equivalent)
rather than events[0].
In `@demos/user-registration/src/Final/UserRegistered.php`:
- Around line 45-47: The current check reads $this->been->events[0] which
assumes the new UserCreatedContext is the first event; make the proof resilient
by locating the actual UserCreatedContext that matches the test email instead of
indexing [0]. In the test surrounding $this->been->events and assertions, search
through $this->been->events for an instance of UserCreatedContext with ->email
=== $this->email (or take the last event if you intend "most recent"), then
assert that such an event was found and that its email equals $this->email;
update references to $event accordingly so the assertion no longer depends on a
fixed index.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6ae710e9-4ac0-4f7c-841d-a9539f224909
📒 Files selected for processing (11)
README.ja.mdREADME.mddemos/contact-form/src/Context/ReceiptGeneratedContext.phpdemos/contact-form/src/Final/ContactReceived.phpdemos/medical-triage/src/Module/AppModule.phpdemos/order-processing/src/Context/OrderFinalizedContext.phpdemos/order-processing/src/Final/OrderConfirmed.phpdemos/order-processing/src/Module/AppModule.phpdemos/order-processing/tests/Final/OrderConfirmedTest.phpdemos/user-registration/src/Context/UserCreatedContext.phpdemos/user-registration/src/Final/UserRegistered.php
Inject Been into Final objects that have meaningful domain events to record. The Final asserts its own causal chain in production code, moving proof from test files into the domain. Demos with Been: - contact-form: receipt↔email link - user-registration: email causal chain (assert) - order-processing: moment completion status (assert) Demos without Been (no meaningful context to prove): hello-world, blog-publishing, medical-triage, loan-application, insurance-claim Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
Beeninto Final objects with meaningful domain eventsassert()— proof lives in production code, not test filesDemos with Been
Demos without Been (no meaningful context)
hello-world, blog-publishing, medical-triage, loan-application, insurance-claim
Test plan
contact-form: 11 tests passuser-registration: 13 tests passorder-processing: 66 tests pass🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
New Features