Description

When a wildcard observer is queued to run, and a different batched property re-sets a dependency to the observer, the nested call to the observer returns the correct information, but the initially queued observer runs with a stale value in the info argument.

Live Demo

Setup: The trigger dependency causes computeArray to be run with an uninitialized size (defaults to 0); at this point the arrayChanged observer is queued to run, but before it does the trigger observer runs and sets size to 1. This causes a nested invocation of computeArray and arrayChanged to be run first (with the correct info information reflecting the new array size of 1). However, when the processing unrolls back to the initially queued invocation of arrayChanged, it runs with stale info information.

3.x: https://jsbin.com/babeyaz/1/edit?html,console,output (wrong)
1.x: https://jsbin.com/vojode/edit?html,console,output (correct)

Expected Results

info.value.length always matches this.array.length at the time the observer runs.

Actual Results

The initial observer invocation (which runs last, due to a re-entrant change after it was enqueued) returns info.value.length == 0 while this.array.length == 1.

Note that in 3.x, the observer runs twice, while in 1.x it only runs once. This is expected, since in 1.x the initial call to computeArray is aborted because of the "undefined" rule (the size argument is yet undefined); however in 2.x comptueArray runs first due to trigger, and subsequently due to size. That is WAI, however the info should always reflect the current state of the world

Browsers Affected

All

Versions

• Polymer: v3.x, v2.x