Skip to content

fix(amazonq): Ensure active customization has profile filled to support proper validation #5611

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 62 commits into from

Conversation

evanliu048
Copy link
Contributor

@evanliu048 evanliu048 commented Apr 21, 2025

Fix bug introduced by #5591.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Description

This PR addresses an edge case where activeCustomization.profile is null, which causes the plugin to skip the invalidation logic due to the current conditional check.

This situation might occur for legacy users whose selected customizations were saved before the profile field was introduced. If the profile is missing, the plugin now attempts to recover the profile by matching the arn from the aggregated customization list.
In the profile validation logic (step 4), added a fallback mechanism:

If activeCustomization.profile == null, search the fetched list for a matching arn and backfill the profile.

Checklist

  • My code follows the code style of this project
  • I have added tests to cover my changes
  • A short description of the change has been added to the CHANGELOG if the change is customer-facing in the IDE.
  • I have added metrics for my changes (if required)

License

I confirm that my contribution is made under the terms of the Apache 2.0 license.

@evanliu048 evanliu048 requested review from a team as code owners April 21, 2025 21:34
# Conflicts:
#	plugins/amazonq/codewhisperer/jetbrains-community/src/software/aws/toolkits/jetbrains/services/codewhisperer/customization/CodeWhispererModelConfigurator.kt
@evanliu048 evanliu048 closed this Apr 22, 2025
@evanliu048
Copy link
Contributor Author

Let's revert this change for now.

We're not 100% confident it won't cause further regressions—especially since we're already seeing throttling and usage drop. The team wants to prioritize the first two issues before revisiting customization.

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.

3 participants