I am currently facing significant challenges when it comes to optimizing a notification bot created with Teams Toolkit.
One of the main issues I'm encountering is related to the following code snippet:
const member = await notificationApp.notification.findMember( async (m) => m.account.email === email );This particular operation is taking too long to execute. Even with just 50 members, it is taking around 1 minute to complete, resulting in almost an hour to send 50 individual messages.
To address this problem, I decided to implement a Redis service on Azure and store user data in Redis to reduce the time required to retrieve user information. However, I am struggling to construct the Member object based on the data saved in Redis. Since Redis only supports JSON storage, I stored whatever information I could extract and attempted to create a Member class instance using its constructor. Here is my current approach:
let memberFromRedis = await getMemberFromRedis(email); const account = memberFromRedis["account"] as TeamsChannelAccount;
const conversationReference = memberFromRedis["parent"]["conversationReference"];
const teamsBotInstallation = await notificationApp.notification.buildTeamsBotInstallation(conversationReference);
// @ts-ignore const user = new Member(teamsBotInstallation , account);
The reason for using ts-ignore is due to encountering an unusual type error that states:
Argument type 'TeamsBotInstallation_2' is not assignable to parameter type 'TeamsBotInstallation'. Property types are not compatible - 'CloudAdapter' properties are missing several key properties found in 'BotFrameworkAdapter': TokenApiClientCredentialKey, credentials, credentialsProvider, settings, and 41 others.
However, upon reviewing the types used, TeamsBotInstallation_2 is explicitly declared as equivalent to TeamsBotInstallation. So, they should theoretically be of the same type, right?
Despite this observation, I continue to encounter errors while attempting to call the await user.sendMessage("test"); function, which results in the following error message:
{ "code": "Internal", "message": "Error: CloudAdapterBase.continueConversationis deprecated, please use CloudAdapterBase.continueConversationAsync" }
It appears that there are discrepancies between the expected Member class and the actual return type from the findMember(Member_2) method, even though both types are supposedly defined as identical according to the exported types seen in codebase.
During debugging, a subtle difference was noted:here
The functions, such as sendAdaptiveCard, seem to reference different locations and exhibit varying object types.
Could this discrepancy be the root cause of the issue? If so, how can I effectively resolve it?
I have explored various methods such as creating the Member object directly from its constructor, parsing with JSON, and utilizing 'as Member', but unfortunately, none of these approaches have yielded success.