Conversation
|
Important Review skippedAuto reviews are disabled on this repository. To trigger a review, include ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
|
|
||
| // Reflect the canonicalized address in the visible input so that what | ||
| // the user sees matches what will be submitted. | ||
| setInputValue(finalSelection.formattedAddress); |
There was a problem hiding this comment.
🟡 Setting input to validated address triggers spurious autocomplete API request and orphaned billing session
After resolveSelection clears the autocomplete cache/session (setCache({}), token.current = null at useAddressAutocomplete.ts:131-133), calling setInputValue(finalSelection.formattedAddress) changes searchQuery, which causes the useEffect at useAddressAutocomplete.ts:39-86 to fire. Because the cache is empty and the token is null, a brand-new AutocompleteSessionToken is created and a fetchAutocompleteSuggestions request is dispatched for the validated address text. This session is never completed with a fetchFields call, resulting in an orphaned billing session on every address selection where the validated formatted address differs from the original autocomplete text.
Trace of the issue
resolveSelectionclears cache/token (line 131-133 of useAddressAutocomplete.ts)setInputValue(finalSelection.formattedAddress)changesinputValue→searchQuerychanges- Effect fires:
token.currentis null → new token created,prev[searchQuery]is undefined → newfetchAutocompleteSuggestionsfired - No subsequent
fetchFieldscompletes this session → orphaned session billed at higher rate
Prompt for agents
Both BatteryAddressSearchFlow.tsx (line 94) and EnergyOnlyAddressEntryFlow.tsx (line 105) set the input value to the validated formatted address after resolveSelection has cleared the autocomplete cache and session token. This causes useAddressAutocomplete's effect (useAddressAutocomplete.ts:39-86) to start a new autocomplete session and fire a request for the validated address text, which is never completed.
Possible fixes:
1. Add a flag/ref in useAddressAutocomplete that suppresses the next autocomplete request (e.g., a skipNextQuery ref that the resolveSelection callback sets, and the effect checks before firing).
2. Have resolveSelection return the validated text so the hook can pre-populate it in the cache without firing a request.
3. Move the setInputValue call before resolveSelection clears the cache, though this may require rethinking the sequencing.
The same fix needs to be applied to both BatteryAddressSearchFlow.tsx:94 and EnergyOnlyAddressEntryFlow.tsx:105.
Was this helpful? React with 👍 or 👎 to provide feedback.
| console.log("[bpc-web-components] validateAddress request:", { | ||
| addressLine, | ||
| body: requestBody, | ||
| }); |
There was a problem hiding this comment.
🔴 Debug console.log statements left in production code leak user address data
Seven console.log calls were added across addressValidation.ts and useAddressAutocomplete.ts that log full API request bodies (containing user addresses), full API response payloads, session tokens, and place details to the browser console. The codebase had zero console.log calls prior to this PR (only one console.error for actual error handling at modal/UtilitySelectionModal.tsx:75). These are clearly debug statements that should be removed before merging — they expose user PII (home addresses) in the browser console on every production site that embeds this widget.
Prompt for agents
Remove all 7 console.log statements added in this PR. They are located at:
- addressValidation.ts lines 62-65 (validateAddress request)
- addressValidation.ts lines 76-79 (non-ok response)
- addressValidation.ts lines 84-87 (validateAddress response with full data payload)
- addressValidation.ts line 105 (catch error)
- useAddressAutocomplete.ts lines 60-63 (autocomplete request with session token)
- useAddressAutocomplete.ts lines 73-76 (autocomplete response with suggestions)
- useAddressAutocomplete.ts lines 113-119 (fetchFields response with full place details)
The codebase convention is to not use console.log (only console.error for actual errors). These logs expose user home addresses and API response data in the browser console.
Was this helpful? React with 👍 or 👎 to provide feedback.
Uh oh!
There was an error while loading. Please reload this page.