feat: Adds error handling around actor deactivation #628
Conversation
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
@MrMint see the failing test |
Signed-off-by: Jared Prather <[email protected]>
| res.statusCode = HttpStatusCode.OK; | ||
| return this.handleResult(res, result); | ||
| case DeactivateResult.Error: | ||
| res.statusCode = HttpStatusCode.INTERNAL_SERVER_ERROR; |
There was a problem hiding this comment.
Does returning specific http status codes for the unhappy path provide value to the dapr sidecar?
It will be a few days before I can take a look at setting up those e2e tests locally. I'd be a little surprised if this code broke those. Looks like they may be failing historically https://github.com/dapr/js-sdk/actions/workflows/test-e2e.yml |
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Description
Avoid crashing the app when either a deactivate request for a non-activated actor is received or an actors onDeactivate() throws an error. Let me know if this is on the right track or if a different pattern would be preferred and I'll take a look at updating/adding tests. I took a look at a few of the other sdk implementations and it wasn't clear to me if returning specific http statuses to daprd adds value.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #627
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list: