Support different sets of credentials for the kinesis stream and dynamodb state table
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 18
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Description
Currently, the set of credentials Kine uses, whether explicitly provided in the constructor options object (`options.accessKeyId`, `options.secretAccessKey `, `options.sessionToken`) or sourced from other places by the aws-sdk, are used for both the Kinesis stream and Dynamodb state table API calls. While a bit of an edge case, we should support the ability to specify different sets of credentials for these two different APIs. I'd propose keeping the current options as listed above, but if either the `kinesisAccessKeyId` (and related) options or the `dynamoAccessKeyId` (and related) options are set, use *those* sets of credentials for that service. If not specified, that service would fall back to the "global" options (i.e. `options.accessKeyId`), and if those options are not specified either, the other valid credentials the aws-sdk gets.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the constructor options and the code that creates or uses the Kinesis and DynamoDB clients. Trace how the global accessKeyId, secretAccessKey, and sessionToken reach each service, then verify that service-specific options override them while unspecified credentials fall back to the global options or the AWS SDK defaults.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, javascript
- Domain
- backend, cloud, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100