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(core): Adding fuzzy error mapping in core #468

Closed
3 tasks done
tripott opened this issue Feb 10, 2022 · 0 comments · Fixed by #471
Closed
3 tasks done

feat(core): Adding fuzzy error mapping in core #468

tripott opened this issue Feb 10, 2022 · 0 comments · Fixed by #471
Assignees
Labels
Milestone

Comments

@tripott
Copy link
Contributor

tripott commented Feb 10, 2022

In most cases, hyper adapters will return a resolved promise with either a hyper success response or a hyper error.

In the case of unhandled exceptions, an adapter may return a rejected promise with any value.

Core needs to implement some fuzzy mapping such that the value in a rejected promise is mapped to a hyper error and transformed into a resolved promise. It should also attach the originalError to the rejected promise value.

The only time core should return a rejected promise to the hyper app is if there is a catastrophic error within the core.

  • Identify the branch in core that handles rejected promises from adapters
  • Add Zod Error detection and mapping
  • Add generic Error mapping
@tripott tripott added the errors label Feb 10, 2022
@tripott tripott added this to the Z milestone Feb 10, 2022
@tripott tripott changed the title Adding fuzzy error mapping in core feat(core): Adding fuzzy error mapping in core Feb 10, 2022
TillaTheHun0 added a commit that referenced this issue Mar 2, 2022
fix: update all ports to support success + error union response #468
TillaTheHun0 added a commit that referenced this issue Mar 8, 2022
…ponses #468

Since errors can be resolved now, there was a chance that hyper errors
would be ran through the data service id mapping and monitoring chain.
With this change only successful responses will flow through the mapping
and monitoring

The id monitoring will go away, but shouldn't affect the code flow
with these changes
TillaTheHun0 added a commit that referenced this issue Mar 8, 2022
fix(core): only run data service id mapping/monitoring on success responses #468
TillaTheHun0 added a commit that referenced this issue Mar 21, 2022
feat(core): indicate error in event payload from core #468
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants