If an indirect dependency resolves to something other than a semver (or
a GitHub tarball), it will be stored in the 'resolved'. Our shrinkwrap
minifier (which helps to reduce spurious shrinkwrap file changes) needs
to recognize that.
Also, consistently use the "version" field in the minified shrinkwrap
file (which a comment already claimed we could do).
Fixes#1684.
We should never use the existence of a directory in our source tree to
make a decision, because git doesn't track directory existence, and it's
easy to end up with extraneous directories (containing gitignored files,
eg). So we should ignore programs/foo directories in apps if they don't
contain package.js.
There was a race condition in the manipulation of the write fence by the
drop collection code. Specifically, when seeing a "drop collection"
oplog entry, OplogObserveDriver took no immediate action and instead
deferred some "should I re-poll now or later?" logic.
This allowed the write fence's oplogHandle.waitUntilCaughtUp code to
think that everything was "caught up" even though the effects of the
"drop collection" entry had not yet affected the cursor's state (by
transitioning it away from the STEADY state). The fix is to ensure that
the state-change aspects of processing the entry occur immediately; the
actual re-query is still deferred in order to not block the oplog tailer
from continuing.
Reported by: @awwx
(The previous failure can made consistently reproducible by replacing the
`Meteor.defer` that is removed by this commit with a
`Meteor.setTimeout(,200)`.)
There was a race condition in the manipulation of the write fence by the
drop collection code. Specifically, when seeing a "drop collection"
oplog entry, OplogObserveDriver took no immediate action and instead
deferred some "should I re-poll now or later?" logic.
This allowed the write fence's oplogHandle.waitUntilCaughtUp code to
think that everything was "caught up" even though the effects of the
"drop collection" entry had not yet affected the cursor's state (by
transitioning it away from the STEADY state). The fix is to ensure that
the state-change aspects of processing the entry occur immediately; the
actual re-query is still deferred in order to not block the oplog tailer
from continuing.
Reported by: @awwx
(The previous failure can made consistently reproducible by replacing the
`Meteor.defer` that is removed by this commit with a
`Meteor.setTimeout(,200)`.)
