Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1885463002:
Create a Promise class to simplify dealing with async results. (Closed)
DescriptionCreate a Promise class to simplify dealing with async results.
BUG=It's a feature!
TBR=thakis@chromium.org
Committed: https://crrev.com/63e6b5040e27c476cd1303520a2627997560e605
Cr-Commit-Position: refs/heads/master@{#401846}
Patch Set 1 #
Total comments: 4
Patch Set 2 : #
Total comments: 8
Patch Set 3 : #Patch Set 4 : #
Total comments: 6
Patch Set 5 : #Patch Set 6 : #
Total comments: 2
Patch Set 7 : #
Total comments: 4
Patch Set 8 : #
Total comments: 2
Patch Set 9 : #Patch Set 10 : #
Total comments: 2
Patch Set 11 : #
Total comments: 8
Patch Set 12 : Redid then(Callback) #Patch Set 13 : Use android_support_v23, not android_support_annotations #Patch Set 14 : Specify types for generics. #Patch Set 15 : Remove IntDef #Messages
Total messages: 66 (22 generated)
peconn@chromium.org changed reviewers: + bauerb@chromium.org, dgn@chromium.org
Can you put up a change that uses this? Maybe even in this CL, or as a separate one.
https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... base/android/java/src/org/chromium/base/Promise.java:32: public void then(Callback<T> callback) { how about failure conditions? except() or catch(), maybe with a different argument type to be provided?
https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... base/android/java/src/org/chromium/base/Promise.java:32: public void then(Callback<T> callback) { On 2016/04/12 11:15:24, dgn wrote: > how about failure conditions? except() or catch(), maybe with a different > argument type to be provided? I would be a bit wary about adding things that aren't used yet. Better to add a barebones implementation and then add things as necessary. Torne did make a good point offline though about running callbacks asynchronously, to make callers not have to deal with reentrancy issues.
I posted the callbacks to the Looper to prevent the UI thread getting blocked too much. I changed SyncUserDataWiper to return a Promise instead of taking a callback. It gives an example of the transformation, but it doesn't really simplify things much. I could see greater potential for cases where we have a cache of things that are in the process of being loaded (eg, InterestsItemView.ImageHolder).
https://codereview.chromium.org/1885463002/diff/20001/base/android/java/src/o... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/20001/base/android/java/src/o... base/android/java/src/org/chromium/base/Promise.java:39: callback.onResult(mResult); I think you may also want want to run this callback asynchronously, to prevent reentrancy issues. https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java:556: Promise<Void> promise = (wipeData I'm thinking that it would be nice to extract this into a method as well, but I'm not really sure where that should live... SyncUserData doesn't seem quite right. Maybe SigninManager? (Because really, this is preparation for signing in) https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/sync/SyncAccountSwitcher.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/sync/SyncAccountSwitcher.java:74: SigninManager.get(mActivity).signOut(new Runnable() { I guess this would also become a bit nicer with signOut() returning a Promise, and implementing chaining...
I updated InterestsItemView to use Promises as that gives a slightly better argument for their inclusion.
I added Promise chaining, PTAL. https://codereview.chromium.org/1885463002/diff/20001/base/android/java/src/o... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/20001/base/android/java/src/o... base/android/java/src/org/chromium/base/Promise.java:39: callback.onResult(mResult); On 2016/04/13 16:24:21, Bernhard Bauer wrote: > I think you may also want want to run this callback asynchronously, to prevent > reentrancy issues. Done.
Nice! https://codereview.chromium.org/1885463002/diff/60001/base/android/java/src/o... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/60001/base/android/java/src/o... base/android/java/src/org/chromium/base/Promise.java:40: * instantly if the Promise is already fulfilled. Nit: not instantly, on the next iteration of the message loop. https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java (right): https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:140: new ImageDownloadTask(mInterest.getImageUrl(), promise, getResources()).execute(); You might want to call executeOnExecutor(THREAD_POOL_EXECUTOR) to use more than one thread. https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:203: public ImageDownloadTask(String url, Promise<Drawable> promise, Resources resources) { Instead of passing the promise into the constructor, I would make a static method that executes the task and returns the promise.
https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... base/android/java/src/org/chromium/base/Promise.java:32: public void then(Callback<T> callback) { On 2016/04/12 11:15:24, dgn wrote: > how about failure conditions? except() or catch(), maybe with a different > argument type to be provided? Acknowledged. https://codereview.chromium.org/1885463002/diff/1/base/android/java/src/org/c... base/android/java/src/org/chromium/base/Promise.java:32: public void then(Callback<T> callback) { On 2016/04/12 11:17:35, Bernhard Bauer wrote: > On 2016/04/12 11:15:24, dgn wrote: > > how about failure conditions? except() or catch(), maybe with a different > > argument type to be provided? > > I would be a bit wary about adding things that aren't used yet. Better to add a > barebones implementation and then add things as necessary. > > Torne did make a good point offline though about running callbacks > asynchronously, to make callers not have to deal with reentrancy issues. Done. https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java:556: Promise<Void> promise = (wipeData On 2016/04/13 16:24:21, Bernhard Bauer wrote: > I'm thinking that it would be nice to extract this into a method as well, but > I'm not really sure where that should live... SyncUserData doesn't seem quite > right. Maybe SigninManager? (Because really, this is preparation for signing in) You mean extract this? Promise<Void> promise = (wipeData ? SyncUserDataWiper.wipeSyncUserData() : Promise.fulfilled((Void) null)); into a 'Promise<Void> wipeSyncUserDataIfRequired(boolean required)'? https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/sync/SyncAccountSwitcher.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/sync/SyncAccountSwitcher.java:74: SigninManager.get(mActivity).signOut(new Runnable() { On 2016/04/13 16:24:21, Bernhard Bauer wrote: > I guess this would also become a bit nicer with signOut() returning a Promise, > and implementing chaining... Done. https://codereview.chromium.org/1885463002/diff/60001/base/android/java/src/o... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/60001/base/android/java/src/o... base/android/java/src/org/chromium/base/Promise.java:40: * instantly if the Promise is already fulfilled. On 2016/05/26 09:31:08, Bernhard Bauer wrote: > Nit: not instantly, on the next iteration of the message loop. Done. https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java (right): https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:140: new ImageDownloadTask(mInterest.getImageUrl(), promise, getResources()).execute(); On 2016/05/26 09:31:08, Bernhard Bauer wrote: > You might want to call executeOnExecutor(THREAD_POOL_EXECUTOR) to use more than > one thread. Done. https://codereview.chromium.org/1885463002/diff/60001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:203: public ImageDownloadTask(String url, Promise<Drawable> promise, Resources resources) { On 2016/05/26 09:31:08, Bernhard Bauer wrote: > Instead of passing the promise into the constructor, I would make a static > method that executes the task and returns the promise. Done.
https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java:556: Promise<Void> promise = (wipeData On 2016/05/31 10:29:55, PEConn1 wrote: > On 2016/04/13 16:24:21, Bernhard Bauer wrote: > > I'm thinking that it would be nice to extract this into a method as well, but > > I'm not really sure where that should live... SyncUserData doesn't seem quite > > right. Maybe SigninManager? (Because really, this is preparation for signing > in) > > You mean extract this? > > Promise<Void> promise = (wipeData > ? SyncUserDataWiper.wipeSyncUserData() > : Promise.fulfilled((Void) null)); > > into a 'Promise<Void> wipeSyncUserDataIfRequired(boolean required)'? Yup, exactly.
peconn@chromium.org changed reviewers: + torne@chromium.org
torne@ Could you please take a look at the base/android stuff? https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... File chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java (right): https://codereview.chromium.org/1885463002/diff/20001/chrome/android/java/src... chrome/android/java/src/org/chromium/chrome/browser/signin/AccountSigninView.java:556: Promise<Void> promise = (wipeData On 2016/05/31 14:26:27, Bernhard Bauer wrote: > On 2016/05/31 10:29:55, PEConn1 wrote: > > On 2016/04/13 16:24:21, Bernhard Bauer wrote: > > > I'm thinking that it would be nice to extract this into a method as well, > but > > > I'm not really sure where that should live... SyncUserData doesn't seem > quite > > > right. Maybe SigninManager? (Because really, this is preparation for signing > > in) > > > > You mean extract this? > > > > Promise<Void> promise = (wipeData > > ? SyncUserDataWiper.wipeSyncUserData() > > : Promise.fulfilled((Void) null)); > > > > into a 'Promise<Void> wipeSyncUserDataIfRequired(boolean required)'? > > Yup, exactly. Done.
LGTM https://codereview.chromium.org/1885463002/diff/100001/chrome/android/java/sr... File chrome/android/java/src/org/chromium/chrome/browser/signin/SigninManager.java (right): https://codereview.chromium.org/1885463002/diff/100001/chrome/android/java/sr... chrome/android/java/src/org/chromium/chrome/browser/signin/SigninManager.java:611: * wiped, if the parameter is true or an already fulfilled Promise if the parameter is false. Nit: I think the comma should go before the "or", to separate the two options.
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1885463002/120001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Ping for an LGTM for base. https://codereview.chromium.org/1885463002/diff/100001/chrome/android/java/sr... File chrome/android/java/src/org/chromium/chrome/browser/signin/SigninManager.java (right): https://codereview.chromium.org/1885463002/diff/100001/chrome/android/java/sr... chrome/android/java/src/org/chromium/chrome/browser/signin/SigninManager.java:611: * wiped, if the parameter is true or an already fulfilled Promise if the parameter is false. On 2016/06/01 12:35:09, Bernhard Bauer wrote: > Nit: I think the comma should go before the "or", to separate the two options. Done.
No way to handle exceptions? https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:27: public interface Function<R, A> { This (and the below interface) have their type parameters reversed compared to java.util.function.Function (in java 8). Maybe we should match that? https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:144: new Handler(Looper.myLooper()).post(new Runnable() { No need to pass looper explicitly, new Handler() already works. However, do we really want to make a new handler every time? It does stuff in its constructor..
I have implemented Promise rejections. https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:27: public interface Function<R, A> { On 2016/06/03 14:50:17, Torne wrote: > This (and the below interface) have their type parameters reversed compared to > java.util.function.Function (in java 8). Maybe we should match that? Done. https://codereview.chromium.org/1885463002/diff/120001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:144: new Handler(Looper.myLooper()).post(new Runnable() { On 2016/06/03 14:50:17, Torne wrote: > No need to pass looper explicitly, new Handler() already works. However, do we > really want to make a new handler every time? It does stuff in its constructor.. Done.
Awesome! https://codereview.chromium.org/1885463002/diff/140001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/140001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:114: private void exceptInner(Callback<Exception> onReject) { I think we could expose except() publicly, so that clients can add individual exception handlers without also having to handle fulfillment.
https://codereview.chromium.org/1885463002/diff/140001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/140001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:114: private void exceptInner(Callback<Exception> onReject) { On 2016/06/08 11:21:09, Bernhard Bauer wrote: > I think we could expose except() publicly, so that clients can add individual > exception handlers without also having to handle fulfillment. Done.
Caused the Promise to fail if |except(Callback)| is called, then |then(Callback)| is called.
lgtm https://codereview.chromium.org/1885463002/diff/180001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/180001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:127: assert !mSingleArgumentThenCalled : "If you wish to provide both a fulfillment and " Remove this?
https://codereview.chromium.org/1885463002/diff/180001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/180001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:127: assert !mSingleArgumentThenCalled : "If you wish to provide both a fulfillment and " On 2016/06/08 15:28:19, Bernhard Bauer wrote: > Remove this? Done.
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/200001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
Generally LGTM with a couple of nits - not sure we should go to the trouble of doing something more complex about handling rejections in chains even though the current implementation seems a bit gross.. https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:89: Callback<Exception> onReject = new Callback<Exception>() { Having to go to the trouble of preventing people from using both then() and except() on the same promise (with checkValidUsage) so that you can have this version of then() do this still seems a bit gross. It's still possible for exceptions to get dropped on the floor if nobody ever calls this particular form of then() on the promise. It seems like the intended usage here is that *all* chains of promises will eventually end with a then() that takes a Callback and "terminates" the chain, but nothing actually prevents someone from just using the form of then() that takes a Function or AsyncFunction instead and then just not doing anything with the promise that's returned. The only way to make sure we don't "lose" the exception in this case would be a finaliser or other GC-detection on the promise. https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:131: checkThread(); Doing checkThread here seems redundant in a bunch of cases (like when it gets used by the functions below) - it seems like it should be sufficient to do this only in public functions to eliminate the redundant checks. https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:135: } else { This seems like it should be "else if (mState == PENDING)" (and similarly in exceptInner) - there's no point in adding a callback if the promise is already fulfilled in the opposite state. https://codereview.chromium.org/1885463002/diff/200001/chrome/android/java/sr... File chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java (right): https://codereview.chromium.org/1885463002/diff/200001/chrome/android/java/sr... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:144: if (!promise.isFulfilled()) { This seems to now have different semantics - previously, if the cached image was already downloaded, it would display it immediately, whereas now it's enqueueing the display of the image with then() - setImage won't be called at all synchronously. Is that okay?
https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... File base/android/java/src/org/chromium/base/Promise.java (right): https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:89: Callback<Exception> onReject = new Callback<Exception>() { On 2016/06/15 12:17:55, Torne wrote: > Having to go to the trouble of preventing people from using both then() and > except() on the same promise (with checkValidUsage) so that you can have this > version of then() do this still seems a bit gross. > > It's still possible for exceptions to get dropped on the floor if nobody ever > calls this particular form of then() on the promise. It seems like the intended > usage here is that *all* chains of promises will eventually end with a then() > that takes a Callback and "terminates" the chain, but nothing actually prevents > someone from just using the form of then() that takes a Function or > AsyncFunction instead and then just not doing anything with the promise that's > returned. The only way to make sure we don't "lose" the exception in this case > would be a finaliser or other GC-detection on the promise. Discussed offline, going for a slightly different approach. https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:131: checkThread(); On 2016/06/15 12:17:55, Torne wrote: > Doing checkThread here seems redundant in a bunch of cases (like when it gets > used by the functions below) - it seems like it should be sufficient to do this > only in public functions to eliminate the redundant checks. Done. https://codereview.chromium.org/1885463002/diff/200001/base/android/java/src/... base/android/java/src/org/chromium/base/Promise.java:135: } else { On 2016/06/15 12:17:55, Torne wrote: > This seems like it should be "else if (mState == PENDING)" (and similarly in > exceptInner) - there's no point in adding a callback if the promise is already > fulfilled in the opposite state. Done. https://codereview.chromium.org/1885463002/diff/200001/chrome/android/java/sr... File chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java (right): https://codereview.chromium.org/1885463002/diff/200001/chrome/android/java/sr... chrome/android/java/src/org/chromium/chrome/browser/ntp/interests/InterestsItemView.java:144: if (!promise.isFulfilled()) { On 2016/06/15 12:17:55, Torne wrote: > This seems to now have different semantics - previously, if the cached image was > already downloaded, it would display it immediately, whereas now it's enqueueing > the display of the image with then() - setImage won't be called at all > synchronously. Is that okay? I don't think this should be an issue. The images here will be loaded asynchronously by normally so the delay waiting for the next iteration of the looper shouldn't be long enough to cause a UX issue.
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/220001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/240001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/260001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by peconn@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/280001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_arm64_dbg_recipe on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...) android_compile_dbg on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...) linux_android_rel_ng on tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
Patchset #15 (id:280001) has been deleted
@bauerb: Do you mind taking one (hopefully) final look over the code?
lgtm
still LGTM as well
The CQ bit was checked by peconn@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from bauerb@chromium.org, torne@chromium.org Link to the patchset: https://codereview.chromium.org/1885463002/#ps300001 (title: "Remove IntDef")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/300001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
Description was changed from ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! ========== to ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! TBR=thakis@chromium.org ==========
The CQ bit was checked by peconn@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1885463002/300001
Message was sent while issue was closed.
Description was changed from ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! TBR=thakis@chromium.org ========== to ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! TBR=thakis@chromium.org ==========
Message was sent while issue was closed.
Committed patchset #15 (id:300001)
Message was sent while issue was closed.
Description was changed from ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! TBR=thakis@chromium.org ========== to ========== Create a Promise class to simplify dealing with async results. BUG=It's a feature! TBR=thakis@chromium.org Committed: https://crrev.com/63e6b5040e27c476cd1303520a2627997560e605 Cr-Commit-Position: refs/heads/master@{#401846} ==========
Message was sent while issue was closed.
Patchset 15 (id:??) landed as https://crrev.com/63e6b5040e27c476cd1303520a2627997560e605 Cr-Commit-Position: refs/heads/master@{#401846} |
