-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix error when a not yet inserted job is updated #7196
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7196 +/- ##
=======================================
Coverage 94.02% 94.02%
=======================================
Files 172 172
Lines 12867 12867
=======================================
Hits 12098 12098
Misses 769 769
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually believe the problem is not in our side but it is probably a bug on MongoDB 4.4. The solution I used was just upsert the job status when updating it.
LGTM, I think we could find out whether it is a MongoDB 4.4 bug if we just run a loop of saving and immediately updating an obj, bypassing first the Parse.Job logic, then bypassing the DB adapter.
Could there be a scenario in which the upsert creates a job that has already been deleted due to a race conditions? I think that should fail gracefully.
Actually, looking at the current run and the error in Postgres, it seems to be the same issue with a different object, so it’s probably not MongoDB related.
|
I don't think so. I am not aware of any code in place that deletes JobStatus. The developers could maybe write a custom code and delete a JobStatus using the master key. I believe that's not a common scenario though. I will try what you suggested anyways and I will check different versions of mongo |
I beleive this one is another Flaky test. I will take a look at it as well. |
After a really hard time understanding what was happening it turned out that the problem was in our side. After every test-case, we delete all the data, but, the process of saving the message and status of a job is asynchronous. So it was happening that, in some cases, the test was finishing (and the data getting deleted) before the status and message update. |
Was the test case not async/await?
I think that would not end the test and delete the data before the test is done. Or even if it is not async/await, the test wouldn't finish before |
The tests currently are like this: it('should define a job', done => {
expect(() => {
Parse.Cloud.job('myJob', () => {});
}).not.toThrow();
request({
method: 'POST',
url: 'http://localhost:8378/1/jobs/myJob',
headers: {
'X-Parse-Application-Id': Parse.applicationId,
'X-Parse-Master-Key': Parse.masterKey,
},
}).then(
() => {
done();
},
err => {
fail(err);
done();
}
);
}); Basically they do the api call to start the job and then call the The changes in this PR makes the tests to wait for the job completition. |
Makes sense now, thanks. Hats off if that finally fixes these tests. 🤞 |
* Fix error when a not yet inserted job is updated * Add entry to changelog * revert the upsert change and fix the test * Revert the change so job execute a single time * Fix other tests with potential similar problem
🎉 This change has been released in version 5.0.0-beta.1 |
🎉 This change has been released in version 5.0.0 |
New Pull Request Checklist
Issue Description
An error can happen if you try to update a job that was just created. Because of this we have flaky tests. The error is easier to reproduce if you change the job message but it can happen even when it completes fast and the status needs to be changed.
Related issue: #7180
Approach
I actually investigated a lot our code and did a lot of tests regarding write concerns, etc, but I didn't find the root cause. I actually believe the problem is not in our side but it is probably a bug on MongoDB 4.4. The solution I used was just upsert the job status when updating it. Since it fixes the problem and I can't see any downside, I believe it is an acceptable solution.
TODOs before merging