fix(postgres): honor user-supplied ssl config in vector store connection

[gaurav0107]

Summary

The Postgres vector store cannot connect to databases that present a custom or self-signed CA chain (AWS RDS, an internal corporate CA). Upserts fail with:

Error: self-signed certificate in certificate chain
Error: unable to verify the first certificate

Root cause: getDriverFromConfig always selects the TypeORM driver, and TypeORMDriver.getPostgresConnectionOptions set the connection ssl field from the boolean SSL toggle after spreading the user's Additional Configuration:

this._postgresConnectionOptions = {
    ...additionalConfiguration, // may contain ssl: { ca, rejectUnauthorized }
    ...
    ssl: this.getSSL(),         // boolean — clobbers the object above
    ...
}

So any richer ssl object a user supplies is silently discarded — even though the Additional Configuration field description explicitly documents ssl as a supported TypeORM option ("Optional TypeORM connection options (e.g. ssl, connectTimeout)"). The only remaining workaround is the global NODE_TLS_REJECT_UNAUTHORIZED=0 env var, which disables TLS verification process-wide and is called out as unsafe by users in the linked issue.

This PR resolves ssl so that a value supplied via Additional Configuration takes precedence over the boolean toggle, and falls back to the toggle when it is absent. The resolution lives in a small dependency-free helper (sslConfig.ts) so it can be unit tested in isolation, mirroring the existing sanitizeDataSourceOptions.ts pattern.

Operators can now point Flowise at an RDS / corporate-CA Postgres with a scoped, per-connection SSL config, for example in Additional Configuration:

{ "ssl": { "rejectUnauthorized": true, "ca": "-----BEGIN CERTIFICATE-----\n..." } }

or, for a self-signed cert:

{ "ssl": { "rejectUnauthorized": false } }

No behaviour changes for existing users: when Additional Configuration does not contain ssl, the boolean toggle drives the connection exactly as before.

Closes #5292
Closes #5351

Verification

• resolvePostgresSSL returns the user-supplied ssl object/boolean when present, else the toggle — covered by a new unit test (sslConfig.test.ts, 5 cases: toggle passthrough, undefined config, object-wins-over-toggle for both toggle states, explicit ssl:false, rejectUnauthorized:false).
• tsc --noEmit on flowise-components: 0 errors.
• eslint on the changed files: 0 errors/warnings.
• prettier --check on the changed files: clean.
• jest (sslConfig.test.ts): 5/5 passing.
• Scope is confined to the Postgres vector store TypeORM connection path; no defaults changed, and the PGVector driver (currently unreachable) is untouched.

[gemini-code-assist]

Code Review

This pull request introduces a new helper function resolvePostgresSSL along with comprehensive unit tests to ensure that user-supplied SSL configurations in the additional settings take precedence over the boolean SSL toggle for Postgres connections. The review feedback suggests simplifying the nullish check in resolvePostgresSSL by using loose equality (!= null) to align with standard JavaScript/TypeScript idioms.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

To align with the repository's general rules, use loose equality (!= null) for nullish checks instead of combining truthiness and typeof checks. This simplifies the condition while remaining safe, as Object.prototype.hasOwnProperty.call handles primitive values gracefully without throwing errors.

Suggested change

	export function resolvePostgresSSL(additionalConfig: Record<string, any> | undefined, sslToggle: boolean): boolean | Record<string, any> {
	if (additionalConfig && typeof additionalConfig === 'object' && Object.prototype.hasOwnProperty.call(additionalConfig, 'ssl')) {
	return additionalConfig.ssl
	}
	return sslToggle
	}
	export function resolvePostgresSSL(additionalConfig: Record<string, any> | undefined, sslToggle: boolean): boolean | Record<string, any> {
	if (additionalConfig != null && Object.prototype.hasOwnProperty.call(additionalConfig, 'ssl')) {
	return additionalConfig.ssl
	}
	return sslToggle
	}

References

1. In JavaScript/TypeScript, use loose equality (== null) as a standard idiom for a 'nullish' check that covers both null and undefined.

[gaurav0107]

Addressed in 06c2dbd — switched to the != null nullish check. Thanks for the review.