-
Notifications
You must be signed in to change notification settings - Fork 13
Resume request when client fails fixes #468 #494
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
Conversation
… resume the request in case of client failure
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #494 +/- ##
==========================================
+ Coverage 83.10% 84.11% +1.01%
==========================================
Files 26 26
Lines 1415 1505 +90
==========================================
+ Hits 1176 1266 +90
Misses 239 239
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@ponyisi @BenGalewsky @gordonwatts ready for review |
|
I'm sorry, @ketan96-m - I don't agree with @ponyisi on this... adding a new database just to avoid updating existing code is just a recipe for technical debt. Please add a new boolean column for |
|
Superseded by #497 |
Resolves #468
Problem
When the client submits the request but encounters client failure, there is no way of resuming the transforms from the last point. The client is forced to rerun the request which triggers the backend again.
Fix
This PR fixes the broken client problem. The client will be able to resume the request from the last point. Given the client submits the same request again (important since the request hash is calculated and compared with any pending requests)
Future scope:
Approach
Created a new instance of tinydb whose sole purpose is to keep track of the transform request submissions.
I had a discussion with @ponyisi whether we should have the cache use additional columns and flags. The cache currently holds the TransformationResults AFTER the request is processed. We could technically have additional columns, but it would mean changing previous cache specific functions.
I propose to create a new instance of tinydb which stores the submitted transform request ( I have named it as
queue). This will allow to add transform request submission related functions to be separate from the cache features. Thus keeping the existing code intact and only adding the necessary steps in between.Also this will allow us to add the future scope (CLI) option without much modification.
Open to design inputs
Details of this PR
queuewhich records each new transform_request