Simplify setting http response after activity processing #398
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ensure that HTTP responses are returned directly from handlers, rather than through event-based callbacks.
Activity processing and response flow:
onActivityhandler inapp.events.tsnow returns aPromise<InvokeResponse>and directly returns the result of processing the activity, rather than just awaiting it.$processfunction inapp.process.tsis refactored to always return anInvokeResponse, handling both normal and error cases, and ensuring response construction is consistent.HttpPlugin interface and implementation updates:
$onActivityevent handler inHttpPluginis now asynchronous and returns aPromise<InvokeResponse>, aligning with the new app contract.HttpPluginnow awaits the activity response and sends it directly to the client, removing the previous pattern of storing pending responses and using callback events.onError,onActivityResponse) and related state management are removed fromHttpPlugin, as response handling is now synchronous with the HTTP request.Type and import consistency:
InvokeResponsetype is imported and used consistently across files to improve type safety and clarity.