Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#15642 closed defect (fixed)

CancelError exception thrown by robot

Reported by: Douglas Hays Owned by: haysmark
Priority: undecided Milestone: 1.8
Component: TestFramework Version: 1.8.0b1
Keywords: Cc:
Blocked By: Blocking:

Description

Run dijit/tests/robot/typematic.html (I tried both Chrome 20 and IE9).
After the first test, the robot calls seqPromise.cancel() which causes a CancelError? exception, although all tests pass.

Attachments (2)

15642_a.patch (1.0 KB) - added by haysmark 7 years ago.
Option A: add setTimeout to robot.js.
15642_b.patch (466 bytes) - added by haysmark 7 years ago.
Option B: add setTimeout to runner.js.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by Douglas Hays

Milestone: tbd1.8
Owner: set to haysmark
Status: newassigned

comment:2 Changed 7 years ago by haysmark

I tried duplicating the first test and still got only one error. We only started noticing it now because of the new promise instrumentation.

comment:3 Changed 7 years ago by bill

This is due to the code I added in [29101], and is actually happening on every test. I don't know why it only displays the error the first time.

[29101] changed robot to use a chain of promises to execute all the "commands" registered via sequence().

It's actually now redundant for the typematic test and other tests to create and return their own Deferred object. It would be better if they just returned the seqPromise promise chain. However, they create their own Deferred for historical reasons, and that's leading to tricky timing between when the tests' Deferred resolves vs. when the chain of promises resolves.

Every robot test fixture is something like:

var d = new doh.Deferred();

...

robot.sequence(d.getTestCallback(function(){
   doh.t(...);
}), 500);

return d;

The sequence of actions is:

  1. all but the last action in the seqPromise queue runs, and the 500ms delay runs too
  2. now the seqPromise queue has 1 item: the callback above
  3. the callback starts and finishes running
  4. getTestCallback() resolves the Deferred "d", triggering this text fixture to end and the new test fixture to start running
  5. before() advice runs, and tries to clear any leftover actions from the previous test

The problem is that even though the final callback function has finished executing, seqPromise hasn't quite yet been marked as fulfilled.

Last edited 7 years ago by bill (previous) (diff)

comment:4 Changed 7 years ago by Douglas Hays

Though not eloquent, a simple setTimeout (and saving the current seqPromise in a local for deferred execution) seems to solve the issue.

Changed 7 years ago by haysmark

Attachment: 15642_a.patch added

Option A: add setTimeout to robot.js.

Changed 7 years ago by haysmark

Attachment: 15642_b.patch added

Option B: add setTimeout to runner.js.

comment:5 Changed 7 years ago by haysmark

Alternatively, as Bill suggested, we could add the setTimeout to runner.js. I was initially worried about putting the setTimeout in robot.js but if we save the seqPromise it should be OK. I attached both versions; if there are no objections, I will commit the robot.js version.

comment:6 Changed 7 years ago by bill

I'm OK with that.

For the record, for 2.0 I'd like to have a cleaner API for writing robot tests. I filed #15644 to track that.

comment:7 Changed 7 years ago by haysmark

Resolution: fixed
Status: assignedclosed

In [29184]:

Allow promise to mark itself as fulfilled before checking to see if it needs to be canceled. Fixes #15642. !strict

comment:8 Changed 5 years ago by Bill Keese <bill@…>

In 59ba49664c1a6b0feb13623be32e10b9679d5cbb/util:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 
Note: See TracTickets for help on using tickets.