race condition referencing circular dependency from plugin

[bill]

This is the intermittent Maqetta failure that Adam mentioned in #13769, triggered by the circular dependency between dojo/dom-construct.js and dojo/dom-attr.js:

1. On Maquetta startup, some module calls the css.js plugin as: davinci/css!davinci/review/resources/Comment.css

2. css.js depends on dojo/dom-construct. Before the css.js plugin runs, dom-construct.js has been loaded, and it's factory has been run. In other words, the construct variable in css.js contains the methods defined in dom-construct.js.

3. However, dojo/dom-construct has a dependency on dojo/dom-attr, and although dom-attr.js is already loaded, it's factory code hasn't been run yet, so require("dojo/dom-attr") === {}.

4. Thus the css.js plugin runs, calls construct.create(), which tries to call attr.set() (or something like that), and fails, since the dom-attr.js factory hasn't been run yet.

The failure is complicated to recreate because you need to download and install maquetta, as per the instructions in ​https://github.com/maqetta/maqetta/wiki/Developer-Setup, and then comment out the workaround code added in ​https://github.com/maqetta/maqetta/issues/2047. I tried reducing it to a simpler case but no luck.

I thought you (Rawld) might be able to surmise the problem though given this description, without actually installing maquetta. Maquetta is using the sync loader, and this failure is happening against source (as opposed to a build).

Alternately, if this pattern isn't supposed to work, just let us know. Obviously the dom-construct.js factory shouldn't try to call functions in dom-attr.js, and vice-versa, but is it also true that other module factories shouldn't call functions in dom-attr.js and dom-construct.js? And by corollary that plugins shouldn't call methods in dom-attr.js and dom-construct.js? If so, the circular dependency just needs to be broken.

[Adam Peller]

Maqetta is using the asynch loader

[bill]

I stand corrected.

Accidentally assigned this to myself, meant to give it to Rawld. Although again, I'm not sure if it's a bug or just unsupported. It's certainly a corner case, so I'm fine to say that it's not supported.

[Rawld Gill]

test case with plugin with circular dependency

[Rawld Gill]

If I understand Bill's description, this should work correctly (assuming a rational build system like Dojo's). fwiw, I created and attached a test case that has a plugin that depends on dojo/dom-construct together with a build that puts all the req'd modules in a single layer (the dojo layer). To exercise the test case, unzip and place the tree as a sibling of dojo, run the build like this

path/to/dtk/util/buildscripts:./build.sh -p ../../circle-with-plugin/circle-with-plugin -r

and then load

path/to/dtk/circle-with-plugin/test.html

in the browser. I tried all kinds of combinations of loading dom-construct/attr before the plugin and it always worked perfectly.

It concerns me that maqetta seems to have an intermittent failure mode. If would be great if this could somehow be reduced. I recommend building with the switches

--layerOptimize 0 --optimize 0

and with "dojo-trace-api" and "dojo-publish-privates" has features set static true. Then turn tracing circular dependencies on. The easiest way is to just set the flag at the bottom of the built dojo. You can also set via normal config, e.g.,

require({trace:{
"loader-circular-dependency":1
}});

Lastly, the apparent work-around--to put a direct, seemingly-unnecessary dependency on dojo/dom-attr in the plugin--is a good one (kind of a belt and suspenders approach). Can anybody confirm that hack is working.

I'm going to lower the priority of this until I get more feedback.

[bill]

IIRC the problem reproduced against source, not a build, but yeah with your simple testcase (and the one I tried) the problem doesn't reproduce against source or build. It does happen w/the instructions I listed above.

[Rawld Gill]

I believe I found a likely suspect to this problem and fixed in [28456] + [28457]; see #15061.

It would be great if bill or adam could pull trunk and see if this problem has magically disappeared.

[Rawld Gill]

Adam Peller tested trunk against Maqetta and was unable to reproduce the problem. I believe this is a duplicate problem fixed in [28456] (in particular, the change at line 1271).