-
-
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 jasmine 3.4 #5573
Fix jasmine 3.4 #5573
Conversation
@@ -97,11 +97,13 @@ class ParseServer { | |||
|
|||
logging.setLogger(loggerController); | |||
const dbInitPromise = databaseController.performInitialization(); | |||
hooksController.load(); | |||
const hooksLoadPromise = hooksController.load(); |
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.
nice
528eccc
to
fb8be99
Compare
Codecov Report
@@ Coverage Diff @@
## master #5573 +/- ##
==========================================
- Coverage 94.06% 94.01% -0.05%
==========================================
Files 129 129
Lines 9192 9192
==========================================
- Hits 8646 8642 -4
- Misses 546 550 +4
Continue to review full report at Codecov.
|
I think it is all passing now. @acinader can you please take a look? |
@davimacedo this looks good to me and I'll merge it now.
Nice. |
@acinader I can send an additional PR with these:
I can change the name to a shorter one. Maybe "dbLoadCallback" ?
I can tackle this
I am not sure what you mean exactly, but, when changing the name, we can remove the "__" and, instead of returning the promise, we could just call the "dbLoadCallback" when the promise resolves/fails. I think it can be useful in production for some situations. What do you think? |
is a no-op: So if one of the promises it is passed is rejected, we'll still have an unhandled rejection. I suspect that the right thing to do is catch the rejection and then shut the server down in an orderly way with the error message of the rejection. |
I just hit another example...I forgot to start mongo before starting my parse server which results in an
|
Got it. I've just sent 3 PRs (still waiting Travis validate the tests) where serverStartComplete < avoidUnhandledPromiseRejection < removeTestDelays, so you can decide which to merge now and perhaps which can be merged later. "serverStartComplete" just changes the callback name and address - your issue 1; "avoidUnhandledPromiseRejection" improves the way that server initialization rejections are handled in prod according to your suggestion - your issue 3; I also added one test simulating the problem you had (database not started); "removeTestDelays" removes some delays from the tests - your issue 2. I analyzed all the tests delay one-by-one and I'd say there are some different groups: a) 1 unique delay related to server initialization (and I removed) b) few delays related to the problem you mentioned in the community forum (and I solved) c) delays that are important for the test (we will not be able to remove them) d) delays that will require us to change the parse server to have additional callbacks/promises (I think those are hard to be addressed and we can work on them as long as we have opportunity) e) Delays that could be removed changing the test, but not so easy (I think we can work on them later as well. |
Thanks for the thoughtful analysis and solid solution. I think we should go for 'removeTestDelays' which I just reviewed. |
* Fix failing tests * just ignore the test for now. * Bumping jasmine * Fix pg unhandled exception * Improving the way the test is fixed * Fix unhandled failed promise in postgres test * Solving unhandled promise fail on redis test * Returning the excluded test * Fixing package-lock * Fix unhandled promise from redis test
Trying to help on #5502