fix: handle subaccount case in gaec #3876
Conversation
|
Test report for this run is available at: https://test-integrations-dev.s3.amazonaws.com/integrations-test-reports/rudder-transformer/3876/test-report.html |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## hotfix/13112024 #3876 +/- ##
===================================================
- Coverage 89.04% 89.02% -0.03%
===================================================
Files 610 610
Lines 32982 32958 -24
Branches 7797 7787 -10
===================================================
- Hits 29370 29340 -30
+ Misses 3329 3305 -24
- Partials 283 313 +30 ☔ View full report in Codecov by Sentry. |
| const filteredLoginCustomerId = removeHyphens(loginCustomerId); | ||
| response.headers['login-customer-id'] = filteredLoginCustomerId; | ||
| if ( | ||
| (isDefined(Config.subAccount) && Config.subAccount === true) || |
There was a problem hiding this comment.
This logic is based on new UI - so it shouldn't depend on old UI field of subAccount but should depend on new UI field configData
There was a problem hiding this comment.
And raise PR to hotfix branch
There was a problem hiding this comment.
In that case, if configDetails object is not null, you shouldn't execute old logic - right now code is messed up where both old & new flows will be executed once UI is migrated.
There was a problem hiding this comment.
{ rudderAccountId: '25u5whFH7gVTnCiAjn4ykoCLGoC', listOfConversions: ['Page View', 'Product Added'], authStatus: 'active', subAccount: false, configData: '{"customerId": "1234567890"}', customerId: '1234567890', loginCustomerId: '12345', },
updated code, once migration is done will remove old code that is kept as to be backward compatible
aashishmalik
force-pushed
the
fix.subaccount-gaec
branch
from
0bb62cc
to
b004970
Compare
aashishmalik
force-pushed
the
fix.subaccount-gaec
branch
from
b004970
to
db5669b
Compare
| if (isDefinedAndNotNull(configData)) { | ||
| const configDetails = JSON.parse(configData); | ||
| configDetails = JSON.parse(configData); | ||
| customerId = configDetails.customerId; | ||
| if (isDefined(configDetails.loginCustomerId)) { |
There was a problem hiding this comment.
this code piece is not needed
| @@ -45,8 +45,9 @@ const responseBuilder = async (metadata, message, { Config }, payload) => { | |||
| let { customerId, loginCustomerId } = Config; | |||
| const { configData } = Config; | |||
|
|
|||
| let configDetails = {}; | |||
There was a problem hiding this comment.
why let --> you are not updating the variable twice
There was a problem hiding this comment.
earlier was reassigning it so used let, now using ternary condition and const
| @@ -70,6 +71,7 @@ const responseBuilder = async (metadata, message, { Config }, payload) => { | |||
| 'developer-token': getValueFromMessage(metadata, 'secret.developer_token'), | |||
| }; | |||
| response.params = { event, customerId: filteredCustomerId }; | |||
|
|
|||
| if (subAccount) { | |||
There was a problem hiding this comment.
here add additional condition to execute this logic only if !isDefined(configDetails.loginCustomerId)
aashishmalik
force-pushed
the
fix.subaccount-gaec
branch
from
ec1751c
to
4c674df
Compare
|
|
This is no longer required as design got updated now without using cascade component |
What are the changes introduced in this PR?
handle subaccount is false but loginCustomerId is present in config
What is the related Linear task?
Resolves INT-XXX
Please explain the objectives of your changes below
Put down any required details on the broader aspect of your changes. If there are any dependent changes, mandatorily mention them here
Any changes to existing capabilities/behaviour, mention the reason & what are the changes ?
N/A
Any new dependencies introduced with this change?
N/A
Any new generic utility introduced or modified. Please explain the changes.
N/A
Any technical or performance related pointers to consider with the change?
N/A
@coderabbitai review
Developer checklist
My code follows the style guidelines of this project
No breaking changes are being introduced.
All related docs linked with the PR?
All changes manually tested?
Any documentation changes needed with this change?
Is the PR limited to 10 file changes?
Is the PR limited to one linear task?
Are relevant unit and component test-cases added in new readability format?
Reviewer checklist
Is the type of change in the PR title appropriate as per the changes?
Verified that there are no credentials or confidential data exposed with the changes.