Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
src/address-search/fetch.ts
Outdated
| "Content-Type": "application/json", | ||
| }, | ||
| body: JSON.stringify({ selection, confirmAddress }), | ||
| body: JSON.stringify({ selection, confirm_address: confirmAddress, is_energy_only: isEnergyOnly }), |
There was a problem hiding this comment.
🔴 Breaking API change: confirmAddress renamed to confirm_address in request body
The JSON body field confirmAddress was renamed to confirm_address as a side-effect of this PR. This changes the API contract for all address searches, not just energy-only ones.
Root Cause
Previously at src/address-search/fetch.ts:15, the body was:
body: JSON.stringify({ selection, confirmAddress })This PR changed it to:
body: JSON.stringify({ selection, confirm_address: confirmAddress, is_energy_only: isEnergyOnly })The confirmAddress field was renamed to confirm_address (snake_case). If the server-side API expects confirmAddress (camelCase), this will silently break the confirm-address functionality for all users — the server will never see the confirmAddress field and will treat every request as if confirmAddress is false/undefined.
This affects the multiple-address selection flow where confirmAddress: false is explicitly sent (src/address-search/element.tsx:206) and the initial address search where confirmAddress: true is sent (src/address-search/element.tsx:233). If the server doesn't recognize confirm_address, the address confirmation logic will be broken.
Impact: All address searches may have broken confirm-address behavior, potentially causing incorrect routing or infinite loops in the address selection flow.
| body: JSON.stringify({ selection, confirm_address: confirmAddress, is_energy_only: isEnergyOnly }), | |
| body: JSON.stringify({ selection, confirmAddress, is_energy_only: isEnergyOnly }), |
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
backend has been updated
divazbozz
force-pushed
the
david/moe-196-web-component-energy-only-routing-splash-screen
branch
2 times, most recently
from
455a3c2 to
d408e88
Compare
|
we are doing refactor first, converting to draft until that lands |
When is-energy-only="true" is set on the web component, show a 3-second branded splash modal before redirecting to the checkout page. This gives the backend hydration workflow time to complete. - Add is-energy-only attribute to bpc-address-search element - Pass is_energy_only through to address-router POST body - Create EnergyOnlySplashModal with spinning battery SVG and timed redirect - Fold splash into SelectionModal routing (alongside address/utility modals) - Add PostHog tracking for splash shown/redirect/dismissed events Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
divazbozz
force-pushed
the
david/moe-196-web-component-energy-only-routing-splash-screen
branch
from
fde47a9 to
eee9b1b
Compare
divazbozz
deleted the
david/moe-196-web-component-energy-only-routing-splash-screen
branch
2 participants
Summary
is-energy-onlyattribute tobpc-address-searchweb componentis_energy_onlyto the address-router API and shows a 3-second branded splash modal before redirecting to the checkout pageRollout & followup
the energy-only will only be set behind our REP-only website which is not live
design is working on a better splash screen
I will work on refactoring the state a bit in the followup so that the representation is better, instead of 3 separate state variable
Test plan
npm run devwithis-energy-only="true"on the first address search instancesee workflow below
Screen.Recording.2026-02-12.at.4.55.43.PM.mov
🤖 Generated with Claude Code