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.

Sign up for GitHub

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

Jump to bottom

Persist errors and status for reconciliation runs #52

Open
chadlwilson opened this issue Nov 5, 2021 · 1 comment
Open

Persist errors and status for reconciliation runs #52

chadlwilson opened this issue Nov 5, 2021 · 1 comment
Labels
enhancement New feature or request size:S small items
Milestone
Implement error h...

Comments

@chadlwilson
Copy link
Collaborator

Context / Goal

In #12 we persisted the results of successful runs. Additionally, errors are returned via the API, however they are not persisted, so if you retrieve the run later it will just look like it is pending.

Expected Outcome

Out of Scope

Additional context / implementation notes
@chadlwilson chadlwilson added the enhancement New feature or request label Nov 5, 2021
@chadlwilson chadlwilson mentioned this issue Nov 9, 2021
Open
@chadlwilson chadlwilson added the size:S small items label Nov 9, 2021
@chadlwilson chadlwilson self-assigned this Dec 11, 2021
chadlwilson added a commit that referenced this issue Dec 13, 2021
@chadlwilson
#52 Persist status for reconciliation runs
132999d 
Persists only Pending|Successful status at the moment; failure handling to be introduced.
chadlwilson added a commit that referenced this issue Dec 13, 2021
@chadlwilson
#52 Return status of reconciliation runs off the API
b5a0153
chadlwilson added a commit that referenced this issue Dec 13, 2021
@chadlwilson
#52 Add ability to mark a run as failed if data cannot be loaded
d419924 
Failures in most cases will be returned to the user as failed runs rather than 500 errors; and also able to be returned via the API later on.

Still need to return the error message/failure cause, as well as persist the reason for the failure to the database
chadlwilson added a commit that referenced this issue Dec 13, 2021
@chadlwilson
#52 Ensure DB is clean
35cdfb4
chadlwilson added a commit that referenced this issue Dec 13, 2021
@chadlwilson
#52 Return failureCause for runs via the API
fe99bf9 
Still need to
- persist it to the DB for later retrieval after-the-fact
- possibly change the status code to a `4xx` error on the synchronous trigger API when the run is failed
@chadlwilson
Copy link
Collaborator Author

Done

  • Status persisted and returned via API (Pending|Successful|Failed)
  • Runs now return a failureCause via the synchronous trigger API rather than a generic 500 error JSON

Still to do

  • Return 4xx error for source|target DB failures on API rather than HTTP 200?
  • Persist the failureCause messages or structure to the DB so they can be retrieved historically

@jordan396-tw jordan396-tw self-assigned this Jun 8, 2022
@jordan396-tw jordan396-tw mentioned this issue Jun 8, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request size:S small items
Projects
None yet
Milestone
Implement error handling mechanism
Development

No branches or pull requests
2 participants
@chadlwilson @jordan396-tw