Skip to content

dz secret stash #40

Open
divazbozz wants to merge 1 commit intomainfrom
dz/stash-use-validation
Open

dz secret stash #40
divazbozz wants to merge 1 commit intomainfrom
dz/stash-use-validation

Conversation

@divazbozz
Copy link
Copy Markdown
Contributor

@divazbozz divazbozz commented Apr 8, 2026

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 8, 2026

Important

Review skipped

Auto reviews are disabled on this repository. To trigger a review, include rabbit in the PR description. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 45a846e5-d93d-468e-ab23-fd88271c8d10

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch dz/stash-use-validation

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 2 potential issues.

View 4 additional findings in Devin Review.

Open in Devin Review


// Reflect the canonicalized address in the visible input so that what
// the user sees matches what will be submitted.
setInputValue(finalSelection.formattedAddress);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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
  1. resolveSelection clears cache/token (line 131-133 of useAddressAutocomplete.ts)
  2. setInputValue(finalSelection.formattedAddress) changes inputValuesearchQuery changes
  3. Effect fires: token.current is null → new token created, prev[searchQuery] is undefined → new fetchAutocompleteSuggestions fired
  4. No subsequent fetchFields completes 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.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines +62 to +65
console.log("[bpc-web-components] validateAddress request:", {
addressLine,
body: requestBody,
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 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.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant