Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Cached tentant record for context #2025

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

sagarkhole4
Copy link

The getAgentContextForContextCorrelationId function caches the tenant record to avoid the expensive operation of retrieving it from the database each time.

Copy link

changeset-bot bot commented Sep 4, 2024

⚠️ No Changeset found

Latest commit: 58f4c56

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@sagarkhole4 sagarkhole4 changed the title feat:Cached tentant record for context feat: Cached tentant record for context Sep 4, 2024
// TODO: maybe we can look at not having to retrieve the tenant record if there's already a context available.
this.logger.debug('TenantRecord not found in cache')
tenantRecord = await this.tenantRecordService.getTenantById(this.rootAgentContext, contextCorrelationId)
await cache.set(this.rootAgentContext, `contextCorrelationId-${contextCorrelationId}`, tenantRecord)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should only put the tenant record in the cache after we have run the checks for agent storage updates etc.. (so after getContextForSession, and before return the agent context)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I appreciate your suggestion. In line with that, I modified the code.

`contextCorrelationId-${contextCorrelationId}`
)
if (!tenantRecord) {
// TODO: maybe we can look at not having to retrieve the tenant record if there's already a context available.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can be removed

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

)
if (!tenantRecord) {
// TODO: maybe we can look at not having to retrieve the tenant record if there's already a context available.
this.logger.debug('TenantRecord not found in cache')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be helpful to add the ids etc.. to the log messages. So TenantRecord with id ${contextCorrelationId} not found in cache (same for the other log messages)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated all logs

Comment on lines 66 to 70
container.registerInstance(CacheModuleConfig, {
cache: new CacheModule({
cache: new InMemoryLruCache({ limit: 100 }),
}).config.cache as unknown as CacheModule,
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can simplify this

Does this work?

Suggested change
container.registerInstance(CacheModuleConfig, {
cache: new CacheModule({
cache: new InMemoryLruCache({ limit: 100 }),
}).config.cache as unknown as CacheModule,
})
container.registerInstance(CacheModuleConfig, new CacheModuleConfig({
cache: new InMemoryLruCache({ limit: 100 })
})

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, This test case is working I have tested it on my local machine.

Copy link
Contributor

@TimoGlastra TimoGlastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot!

@TimoGlastra TimoGlastra enabled auto-merge (squash) September 5, 2024 14:01
Signed-off-by: Sagar Khole <[email protected]>
auto-merge was automatically disabled September 9, 2024 08:18

Head branch was pushed to by a user without write access

@TimoGlastra
Copy link
Contributor

It seems the lockfile is out of date, and you have to update it locally. ( i think running pnpm install should be enough)

Signed-off-by: Sagar Khole <[email protected]>
@sagarkhole4
Copy link
Author

sagarkhole4 commented Sep 12, 2024

executed pnpm install and committed the pnpm-lock file.

@TimoGlastra
Copy link
Contributor

Tests are now failing as removing a tenant does not remove it from the cache. I think we should remove the tenant record from the cache if a tenant is deleted. I think for every update to the tenant record, we should update the entry in the cache.

And finally, we store the wallet key for the tenant in the wallet record, and so putting it in the cache is not safe I think. Any thoughts on that?

@TimoGlastra
Copy link
Contributor

I think we should maybe only use caching if using Askar profile as multitenant scheme, as in that case the wallet key is not used. But otherwise I'm not sure it's safe to store the wallet key in the cache

@sagarkhole4
Copy link
Author

Tests are now failing as removing a tenant does not remove it from the cache. I think we should remove the tenant record from the cache if a tenant is deleted. I think for every update to the tenant record, we should update the entry in the cache.

And finally, we store the wallet key for the tenant in the wallet record, and so putting it in the cache is not safe I think. Any thoughts on that?

I agree that we should ensure the tenant record is removed from the cache when a tenant is deleted. To address this, we can delete the cached record just before the deletion or update operation is performed. This way, the cache stays in sync with the actual database state.

Regarding the storage of sensitive data like wallet keys, you're right—storing this kind of information directly in the cache could pose a security risk. To mitigate this, we could consider encrypting the data before caching it, ensuring that any sensitive information remains secure.

As fetching data from the database can be resource-intensive, especially in a production environment, caching is a valuable mechanism to enhance performance. By keeping the cache updated efficiently, we can reduce database load and improve response times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants