[fabioKoruja00]

Summary

• Describe the user-facing or operational change.

Related Issues

• Closes #
• Related to #

Target Branch

See the Release Strategy, the
Contribution Golden Path and the
ROADMAP:

• Base is the active release/v3.8.x branch (the highest open release/v*), not main
• New feature? From 3.8.55 on it is held with the v4-feature label for the v4 channel
• Focused templates: append ?template=feature.md or ?template=bugfix.md to the compare URL

Validation

Choose the change type and focused loop from the
Contribution Golden Path. The full unit suite,
Vitest, the 60% coverage gate, and the production build all run in CI on this PR (#8329):

• Change type: provider / routing / UI / i18n / CLI / DB / build-deploy / other
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR
• SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Tests Added Or Updated

• List every changed or added automated test file.
• If no production code changed, state that here.

Coverage Notes

• If this PR changes src/, open-sse/, electron/, or bin/, explain which tests cover the change.
• If coverage moved down in any touched file, explain why and what follow-up task will recover it.

Reviewer Notes

• Call out any risky areas, migrations, feature flags, or manual validation that reviewers should know about.

[diegosouzapw]

Thanks for this — the approach (declared allowlist in providerSpecificDataSecrets.ts, lazy decrypt in both views, cookie dedup on plaintext) reads well and the two new test files are thorough. One regression blocks the merge:

tests/unit/db-encryption.test.ts → "connection field helpers encrypt and decrypt all supported credential fields" fails on b024237f32 (passes on the merge-base 906fb59a05):

+ actual - expected
    {
      accessToken: 'access-123',
      apiKey: 'sk-123',
      idToken: 'id-123',
+     providerSpecificData: undefined,
      refreshToken: 'refresh-123',
      untouched: 'keep-me'
    }

Cause: decryptConnectionFields() now always spreads providerSpecificData into the result, so rows without that column gain an explicit providerSpecificData: undefined key (deepStrictEqual sees it; JSON.stringify would not, which is why the new tests do not catch it).

Minimal fix in src/lib/db/encryption.ts, in the returned object:

    ...(row.providerSpecificData !== undefined ? { providerSpecificData } : {}),

(or only call mapProviderSpecificDataSecrets when row.providerSpecificData is set). Please add the "row without providerSpecificData keeps its exact shape" case to provider-specific-secrets-16836.test.ts so it stays covered.

Everything else I ran on your head is clean: both new test files (20/20), encryption-production-warn-13330, bulk-web-session-import, claude-web-session, complexity ratchets (new-code mode, 0 regressions). The 3 failures in deepseek-web-session-persistence-2942.test.ts are timeouts that fail identically on the base — not yours. CI on this repo is queued behind ~350 runs right now, so the local result is what we have for the moment.

Once the fix lands I will re-run and merge. One request: please stop force-pushing once it is green — the queue restarts on every push and I merge on a stable head.

[diegosouzapw]

Two more items from the targeted typecheck on b024237f32 (the repo's API Route Typecheck job will report the same):

src/lib/db/encryption.ts(374,10): error TS2339: Property 'providerSpecificData' does not exist on type 'T'.
tests/unit/provider-specific-secrets-16836.test.ts(161,25): error TS2339: Property 'credentialDecryptFailed' does not exist on type '{ id: string; provider: string; providerSpecificData: {...} }'.

• encryptConnectionFields<T extends ConnectionFields> reads conn.providerSpecificData, but ConnectionFields does not declare that field — add providerSpecificData?: unknown to the ConnectionFields type (same file) so both the encrypt and decrypt helpers type-check without casts.
• In the test, the row returned by decryptConnectionFields is typed from the input literal, so restored.credentialDecryptFailed needs the helper's return type to carry the optional flag (or type the local as ReturnType<typeof decryptConnectionFields>).

File-size and complexity ratchets are clean on your head; the only ESLint hit (toNumber in lazyConnectionView.ts) is pre-existing and suppressed on the base, not yours.

[diegosouzapw]

Re-checked on 60d979fd61: db-encryption.test.ts 7/7 plus both new suites (25/25 together), targeted typecheck 0 errors, complexity ratchets and file-size clean. Thanks for the quick turnaround.

[fabioKoruja00]

É o mínimo que poderia fazer para ajudar num trabalho excelente como esse que desenvolveu