We are seeing 400 errors from the AWS Lambda integration when calling Skyflow APIs against non-production environments. On inspection, the Lambda client appears to be hard-coded to use the PROD environment, which prevents it from working correctly for other ends.
Specifically, in lambda/skyflow-client.js, the Skyflow client configuration sets the environment as:
const vaultConfig = {
vaultId: vaultId,
clusterId: clusterId,
env: 'PROD',
credentials: credentials
};
This means the Lambda can only successfully target production vaults, regardless of the request context or headers passed in.
Expected Behavior
The Skyflow environment (env) should be configurable at runtime, similar to other request-scoped values (e.g., operation type, data type, context headers).
Proposed Solution
• Remove the hard-coded env: 'PROD'
• Read the environment value from request headers (e.g. sf-env, x-skyflow-env, or similar)
• Pass this value into the Skyflow client configuration when initializing the SDK
• Optionally:
• Default to PROD if no header is provided (backward compatibility)
• Validate allowed values (DEV, STAGING, PROD, etc.)
Why This Matters
• Enables Lambda to work across non-production Skyflow environments
• Unblocks PoCs, previews, and staging deployments
• Aligns environment handling with existing header-based configuration patterns
• Prevents confusing 400 errors when customers are not targeting production
Impact
• Affects AWS Lambda deployments using skyflow-client.js
• No breaking changes if a safe default (PROD) is preserved
References
• File: lambda/skyflow-client.js
• Method: _getClient(clusterId, vaultId)
We are seeing 400 errors from the AWS Lambda integration when calling Skyflow APIs against non-production environments. On inspection, the Lambda client appears to be hard-coded to use the PROD environment, which prevents it from working correctly for other ends.
Specifically, in lambda/skyflow-client.js, the Skyflow client configuration sets the environment as:
const vaultConfig = {
vaultId: vaultId,
clusterId: clusterId,
env: 'PROD',
credentials: credentials
};
This means the Lambda can only successfully target production vaults, regardless of the request context or headers passed in.
Expected Behavior
The Skyflow environment (env) should be configurable at runtime, similar to other request-scoped values (e.g., operation type, data type, context headers).
Proposed Solution
• Remove the hard-coded env: 'PROD'
• Read the environment value from request headers (e.g. sf-env, x-skyflow-env, or similar)
• Pass this value into the Skyflow client configuration when initializing the SDK
• Optionally:
• Default to PROD if no header is provided (backward compatibility)
• Validate allowed values (DEV, STAGING, PROD, etc.)
Why This Matters
• Enables Lambda to work across non-production Skyflow environments
• Unblocks PoCs, previews, and staging deployments
• Aligns environment handling with existing header-based configuration patterns
• Prevents confusing 400 errors when customers are not targeting production
Impact
• Affects AWS Lambda deployments using skyflow-client.js
• No breaking changes if a safe default (PROD) is preserved
References
• File: lambda/skyflow-client.js
• Method: _getClient(clusterId, vaultId)