You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-03-30] NetSuite - Not able to connect the integration with correct tokens, when edit incorrect input #85196
Click "Connect" at NetSuite (upgrade the workspace)
Enter incorrect the NetSuite tokens
Click on the 3 dot menu next to the connection
Enter the correct tokens > Confirm
Disconnect the integration
Click "Connect" at NetSuite
Enter the correct tokens > Confirm
Expected Result:
Entering the Netsuite credentials incorrectly should trigger an error state and RBRs to indicate the connection error, but after edit the credentials should clear the error and connect Netsuite successful.
Actual Result:
Entering the Netsuite credentials incorrectly trigger an error state and RBRs, but after edit the credentials with correct tokens trigger the error "Can’t connect to NetSuite due to an authentication error. Learn more." again and the integration is not connected.
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Identify the pull request that introduced this issue and revert it.
Classification: Frontend bug Causing PR: #83434 - "Fix: Allow updating NetSuite tokens without resetting connection configuration" by @imgyf (High confidence) Related Issues: #82339
Recommendation: ROLL FORWARD
PR #83434 fixes an important issue (preventing configuration reset when updating tokens), but introduced this bug. The fix is simpler than reverting - add optimistic data to clear the authentication error flag when submitting new credentials.
Labels: No changes needed. Keeping DeployBlockerCash as this is a frontend bug requiring an App PR fix.
Detailed Analysis
Evidence
PR #83434 was merged on March 12, 2026 and is included in the v9.3.37-0 staging deploy. It adds a new updateNetSuiteTokens command to allow users to update NetSuite credentials without resetting their entire connection configuration.
The bug reproduction steps match exactly with the new code path introduced by this PR:
Enter incorrect NetSuite tokens → backend sets isAuthenticationError: true on the connection
Click 3-dot menu > Enter credentials
The form detects isAuthenticationError(policy) and calls updateNetSuiteTokens instead of connectPolicyToNetSuite
User enters correct credentials and submits
Error persists because the isAuthenticationError flag is not optimistically cleared
Verification
The bug is in /home/runner/_work/App/App/src/libs/actions/connections/NetSuiteCommands.ts:
The writeNetSuiteCredentials function (lines 21-42) only sets optimistic data for POLICY_CONNECTION_SYNC_PROGRESS:
It does NOT clear the isAuthenticationError flag in the POLICY collection, which is checked by isAuthenticationError() function in /home/runner/_work/App/App/src/libs/actions/connections/index.ts line 264:
When a user submits correct credentials after an authentication error, the frontend should optimistically clear the error state to provide immediate UI feedback. The backend will eventually update this when the sync completes successfully, but without optimistic updates, the error message persists on screen even though the user entered valid credentials.
The fix needs to add optimistic data to clear connections.netsuite.lastSync.isAuthenticationError when updateNetSuiteTokens is called.
Please re-state the problem that we are trying to solve in this issue.
When a user connects NetSuite with incorrect tokens, an authentication error is shown (expected). However, after editing the credentials with correct tokens (via the 3-dot menu > Enter credentials) or disconnecting and reconnecting with correct tokens, the error "Can't connect to NetSuite due to an authentication error" persists and the integration cannot be connected.
What is the root cause of that problem?
PR Expensify/App#83434 (merged March 12, 2026) introduced a regression in NetSuiteTokenInputForm.tsx. It changed the form submission logic to call updateNetSuiteTokens() (which sends the UpdateNetSuiteTokens backend command) when isAuthenticationError is true, instead of always calling connectPolicyToNetSuite() (which sends ConnectPolicyToNetSuite).
The UpdateNetSuiteTokens backend command is designed for existing, fully-initialized connections — it updates credentials and triggers a sync while preserving existing configuration. However, it skips initConnection on the backend.
The problem: when a first-time connection fails with incorrect tokens, the backend sets lastSync.isAuthenticationError = true on the connection object. On the next attempt with correct tokens, isAuthenticationError() at src/libs/actions/connections/index.ts:262-264 returns true, so the form sends UpdateNetSuiteTokens instead of ConnectPolicyToNetSuite. Since the connection was never successfully initialized, the update command fails, and the user is stuck in an error loop.
The isAuthenticationError check does not distinguish between a first-time connection that failed (needs initConnection via ConnectPolicyToNetSuite) and an existing verified connection that lost authentication (can use UpdateNetSuiteTokens).
What changes do you think we should make in order to solve the problem?
The fix should add a check for whether the connection was ever successfully initialized before choosing which API command to use. The isConnectionUnverified() function already exists at src/libs/actions/connections/index.ts:267-273 and checks the NetSuite-specific verified property.
In NetSuiteTokenInputForm.tsx, update the conditional to:
If isAuthenticationError AND the connection is verified (previously working) → use updateNetSuiteTokens (preserves configuration)
If isAuthenticationError AND the connection is unverified (never successfully connected) → use connectPolicyToNetSuite (runs full initConnection)
This preserves the original intent of PR #83434 (not resetting configuration for existing connections) while fixing the regression for first-time connection failures.
What alternative solutions did you explore? (Optional)
Always use ConnectPolicyToNetSuite and handle config preservation on the backend — This would avoid the client-side branching but requires backend changes. More invasive than necessary.
Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.
@ShridharGoel can you provide more details and links for
@madmax330 Can you assign me on this since I've reviewed? Thanks
and
The commit message had Fixes #85196 because of which this got closed on merging.
I'm working on updating our process to have the C+ who reviewed the likely offending PR (as listed in OSBotify's post) to be assigned to deploy blockers issues. Thx
The commit message had Fixes #85196 because of which this got closed on merging
This issue got auto-closed when the PR was merged because the commit had Fixes #85196 which signals GH that the linked issue should be closed once that commit/PR gets merged.
Activity
melvin-bot commentedon Mar 13, 2026
Triggered auto assignment to @madmax330 (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.melvin-bot commentedon Mar 13, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Mar 13, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
OSBotify commentedon Mar 13, 2026
Investigation Summary
Classification: Frontend bug
Causing PR: #83434 - "Fix: Allow updating NetSuite tokens without resetting connection configuration" by @imgyf (High confidence)
Related Issues: #82339
Recommendation: ROLL FORWARD
PR #83434 fixes an important issue (preventing configuration reset when updating tokens), but introduced this bug. The fix is simpler than reverting - add optimistic data to clear the authentication error flag when submitting new credentials.
Labels: No changes needed. Keeping
DeployBlockerCashas this is a frontend bug requiring an App PR fix.Detailed Analysis
Evidence
PR #83434 was merged on March 12, 2026 and is included in the v9.3.37-0 staging deploy. It adds a new
updateNetSuiteTokenscommand to allow users to update NetSuite credentials without resetting their entire connection configuration.The bug reproduction steps match exactly with the new code path introduced by this PR:
isAuthenticationError: trueon the connectionisAuthenticationError(policy)and callsupdateNetSuiteTokensinstead ofconnectPolicyToNetSuiteisAuthenticationErrorflag is not optimistically clearedVerification
The bug is in
/home/runner/_work/App/App/src/libs/actions/connections/NetSuiteCommands.ts:The
writeNetSuiteCredentialsfunction (lines 21-42) only sets optimistic data forPOLICY_CONNECTION_SYNC_PROGRESS:It does NOT clear the
isAuthenticationErrorflag in thePOLICYcollection, which is checked byisAuthenticationError()function in/home/runner/_work/App/App/src/libs/actions/connections/index.tsline 264:Root Cause
When a user submits correct credentials after an authentication error, the frontend should optimistically clear the error state to provide immediate UI feedback. The backend will eventually update this when the sync completes successfully, but without optimistic updates, the error message persists on screen even though the user entered valid credentials.
The fix needs to add optimistic data to clear
connections.netsuite.lastSync.isAuthenticationErrorwhenupdateNetSuiteTokensis called.MelvinBot commentedon Mar 13, 2026
Proposal
Please re-state the problem that we are trying to solve in this issue.
When a user connects NetSuite with incorrect tokens, an authentication error is shown (expected). However, after editing the credentials with correct tokens (via the 3-dot menu > Enter credentials) or disconnecting and reconnecting with correct tokens, the error "Can't connect to NetSuite due to an authentication error" persists and the integration cannot be connected.
What is the root cause of that problem?
PR Expensify/App#83434 (merged March 12, 2026) introduced a regression in
NetSuiteTokenInputForm.tsx. It changed the form submission logic to callupdateNetSuiteTokens()(which sends theUpdateNetSuiteTokensbackend command) whenisAuthenticationErroris true, instead of always callingconnectPolicyToNetSuite()(which sendsConnectPolicyToNetSuite).The
UpdateNetSuiteTokensbackend command is designed for existing, fully-initialized connections — it updates credentials and triggers a sync while preserving existing configuration. However, it skipsinitConnectionon the backend.The problem: when a first-time connection fails with incorrect tokens, the backend sets
lastSync.isAuthenticationError = trueon the connection object. On the next attempt with correct tokens,isAuthenticationError()atsrc/libs/actions/connections/index.ts:262-264returnstrue, so the form sendsUpdateNetSuiteTokensinstead ofConnectPolicyToNetSuite. Since the connection was never successfully initialized, the update command fails, and the user is stuck in an error loop.The critical code is at
src/pages/workspace/accounting/netsuite/NetSuiteTokenInput/subPages/NetSuiteTokenInputForm.tsx:52-56:The
isAuthenticationErrorcheck does not distinguish between a first-time connection that failed (needsinitConnectionviaConnectPolicyToNetSuite) and an existing verified connection that lost authentication (can useUpdateNetSuiteTokens).What changes do you think we should make in order to solve the problem?
The fix should add a check for whether the connection was ever successfully initialized before choosing which API command to use. The
isConnectionUnverified()function already exists atsrc/libs/actions/connections/index.ts:267-273and checks the NetSuite-specificverifiedproperty.In
NetSuiteTokenInputForm.tsx, update the conditional to:isAuthenticationErrorAND the connection is verified (previously working) → useupdateNetSuiteTokens(preserves configuration)isAuthenticationErrorAND the connection is unverified (never successfully connected) → useconnectPolicyToNetSuite(runs fullinitConnection)This preserves the original intent of PR #83434 (not resetting configuration for existing connections) while fixing the regression for first-time connection failures.
What alternative solutions did you explore? (Optional)
Revert PR Fix: Allow updating NetSuite tokens without resetting connection configuration #83434 entirely — This would fix the regression but would re-introduce the original issue ([Due for payment 30th March, 2026] [$250] Allow updating NetSuite tokens without resetting connection configuration #82339) where re-entering credentials on existing connections resets all configuration. Not recommended.
Always use
ConnectPolicyToNetSuiteand handle config preservation on the backend — This would avoid the client-side branching but requires backend changes. More invasive than necessary.Next Steps for Contributor+ team: Reply with
@MelvinBot implement thisto create a draft PR,@MelvinBot <your feedback>to refine this analysis, or explain why you are rejecting Melvin's proposal.fix: use connectPolicyToNetSuite for unverified connections with auth…
ShridharGoel commentedon Mar 13, 2026
@madmax330 Can you assign me on this since I've reviewed? Thanks
28 remaining items
melvin-bot commentedon Mar 30, 2026
Payment Summary
Upwork Job
BugZero Checklist (@mallenexpensify)
melvin-bot commentedon Mar 30, 2026
Payment Summary
Upwork Job
BugZero Checklist (@mallenexpensify)
mallenexpensify commentedon Mar 31, 2026
@ShridharGoel can you provide more details and links for
and
I'm working on updating our process to have the C+ who reviewed the likely offending PR (as listed in OSBotify's post) to be assigned to deploy blockers issues. Thx
ShridharGoel commentedon Mar 31, 2026
@mallenexpensify I had reviewed this: #85200
This issue got auto-closed when the PR was merged because the commit had
Fixes #85196which signals GH that the linked issue should be closed once that commit/PR gets merged.mallenexpensify commentedon Apr 1, 2026
Thanks @ShridharGoel
From here in your PR, do we want retest here to confirm the bug isn't still occurring?
Also.. how much are you due here @ShridharGoel ? I think it's either $250 or $375.
ShridharGoel commentedon Apr 1, 2026
Yes, can we ask for a retest?
Also, any reason you're also considering $375 ?
mallenexpensify commentedon Apr 1, 2026
It looked like there were two PRs to review and one didn't have tests performed (I think, I'd have to go back and find/view links to PRs here)
Requesting retest
m-natarajan commentedon Apr 2, 2026
Not repro, Windows 11 / Chrome, v9.3.51-7
netsuite.mp4
mallenexpensify commentedon Apr 2, 2026
Payment Summary
Contributor+: @ShridharGoel due $250 via NewDot
comment and tag me if ya disagree. Thx
ShridharGoel commentedon Apr 2, 2026
Yeah, the second one was to add unit tests
JmillsExpensify commentedon Apr 6, 2026
$250 approved for @ShridharGoel