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: [#4349] Add new method to expose same functionality as BotFrameworkAdapter.processActivityDirect #332

Conversation

erquirogasw
Copy link

@erquirogasw erquirogasw commented Nov 23, 2022

Fixes # 4349
#minor

Description

This PR exposes the same functionality as the processActivityDirect method of the deprecated BotFrameworkAdapter class. For that, adds a new method that doesn't use HTTP req and res parameters.

Specific Changes

  • New processActivityDirect method that exposes the same functionality that the ones in BotFrameworkAdapter.

Testing

  • All unit tests passed
  • Added unit test for the new method
    image

@coveralls
Copy link

coveralls commented Nov 23, 2022

Pull Request Test Coverage Report for Build 3602737297

  • 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.002%) to 84.638%

Totals Coverage Status
Change from base Build 3595586383: 0.002%
Covered Lines: 19972
Relevant Lines: 22360

💛 - Coveralls

Copy link

@ceciliaavila ceciliaavila left a comment

Choose a reason for hiding this comment

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

The title of the PR should be, if possible: [issue number] Issue title.
Also, in the description, the name of the method is wrong.

@@ -145,6 +144,35 @@ export class CloudAdapter extends CloudAdapterBase implements BotFrameworkHttpAd
}
}

/**
* Exposes the same functionality as [BotFrameworkAdapter.processActivityDirect](https://github.com/microsoft/botbuilder-js/blob/main/libraries/botbuilder/src/botFrameworkAdapter.ts).

Choose a reason for hiding this comment

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

I don't think we should reference a deprecated method in the documentation of a new method. We should explain what the method does. In any case, we could include a comment in the old method referencing this one.

Comment on lines 160 to 165
const validatedActivity = validateAndFixActivity(ActivityT.parse(activity));

if (!validatedActivity.type) {
console.warn('BadRequest: Missing activity or activity type.');
throw new Error('Missing activity or activity type');
}

Choose a reason for hiding this comment

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

This validation seems unnecessary. It was meant to validate the request's body but here you are receiving the activity instead.

throw new Error('Missing activity or activity type');
}

const authHeader = z.string().parse(authorization ?? '');

Choose a reason for hiding this comment

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

I think this is not needed either. The parameter is already a string, why do we need to parse it?

const authHeader = z.string().parse(authorization ?? '');

try {
await this.processActivity(authHeader, validatedActivity, logic);

Choose a reason for hiding this comment

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

Shouldn't we return the invoke response?

Copy link
Author

Choose a reason for hiding this comment

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

Regarding returning the invokeResponse, I'm having the following error. I think it's related to the end const that was created in the previous version. Anyway, in the deprecated class, only the middleware is called. In CloudAdapter, the processActivity method also does it.
image

try {
await this.processActivity(authHeader, validatedActivity, logic);
} catch (err) {
throw new Error(err);

Choose a reason for hiding this comment

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

This doesn't have much sense. We are catching the error to throw it again. Also, be careful with stack exposure (codeQL). I'm not sure if it applies here though.


const mock = sandbox.mock(adapter);
mock.expects('processActivity')
.withArgs('Bearer Authorization', { type: 'invoke', value: 'invoke' }, logic)

Choose a reason for hiding this comment

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

I would declare the activity at the beginning and re-use it later. This way, we don't have duplicated code, and it's also clearer that we are passing an activity as a parameter to the methods.

await adapter.processActivityDirect('Bearer Authorization', { type: 'invoke', value: 'invoke' }, logic);

mock.verify();
});

Choose a reason for hiding this comment

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

Once you review the try-catch block in the method, you should probably add another test to cover the error case.

@erquirogasw erquirogasw changed the title feat: Add new method to expose same functionality as BotFrameworkAdapter.processActivityDirect feat: [#4349] Add new method to expose same functionality as BotFrameworkAdapter.processActivityDirect Nov 24, 2022
Comment on lines 168 to 170
typeof authorization === 'string'
? await this.processActivity(authorization, validatedActivity, logic)
: await this.processActivity(authorization, validatedActivity, logic);

Choose a reason for hiding this comment

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

Does this if/else do the same thing?

Choose a reason for hiding this comment

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

and also why are we throwing again the error, couldnt it just be await this.processActivity(authorization, validatedActivity, logic)?

Choose a reason for hiding this comment

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

There are two overloads of the method. One receives a string, and the other one, an AuthenticateRequestResult. Regarding the error, there's pending feedback to be applied there.

Comment on lines 148 to 150
* Asynchronously creates a turn context and runs the middleware pipeline for an incoming activity.
*
* @param authorization Authorization in format: "Bearer [longString]".

Choose a reason for hiding this comment

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

Suggested change
* Asynchronously creates a turn context and runs the middleware pipeline for an incoming activity.
*
* @param authorization Authorization in format: "Bearer [longString]".
* Asynchronously process an activity running the provided logic function.
*
* @param authorization The authorization header in the format: "Bearer [longString]" or the AuthenticateRequestResult for this turn.

new Error('CloudAdapter.processActivityDirect(): ERROR\n error stack')
);

sandbox.verify();

Choose a reason for hiding this comment

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

Is this line doing something?

@erquirogasw erquirogasw force-pushed the southworks/add/processActivityDirect-functionality-to-CloudAdapter branch from 31fe506 to cd7f7d5 Compare December 2, 2022 14:55
@erquirogasw erquirogasw force-pushed the southworks/add/processActivityDirect-functionality-to-CloudAdapter branch from cd7f7d5 to 7ade736 Compare December 2, 2022 14:58
@erquirogasw
Copy link
Author

erquirogasw commented Dec 2, 2022

Promoted 4380

@erquirogasw erquirogasw closed this Dec 2, 2022
@ceciliaavila ceciliaavila deleted the southworks/add/processActivityDirect-functionality-to-CloudAdapter branch August 17, 2023 16:22
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.

4 participants