Files with extensions requested by registerBatchHandler get saved
directly to the Isopack without being processed.
They will be processed later at bundle time, but that is not yet
implemented.
Due to a type error, _checkUpToDatePreloaded always returned false, so
soft refresh never actually happened. Oops.
This might be (partially?) responsible for #3373.
Follow-up to b556e62262.
Priori to b556e62262, preserveLineNumbers always meant "in an app, not
linking multiple files into a single file" and noLineNumbers always
meant "this is an isopacket, ignoring line numbers for performance (but
still wanting source maps)".
b556e62262 made "noLineNumbers and no source map (eg, JS)" imply
preserveLineNumbers and not creating a source map for the nested
file. But that meant that in the isopacket case, the source map for the
linkered files didn't get you back to the pre-linker case.
This commit reverts to the previous behavior, where noLineNumbers + no
source map + !preserveLineNumbers still generates source maps
representing the linker transform itself.
The original index, "emails.validationTokens.token" is never used in any meteor packages. A search of "validationTokens" across all the packages in `meteor/packages` returns nothing.
The correct index should be, "services.email.verificationTokens.token". This is used in the `verifyEmail` method to locate the correct user record. Without a matching index, this causes a full table scan each time `verifyEmail` is called.
Fixes#4482.
Let's say you call accounts._setLoginToken twice in close succession,
with the same login token. What happens?
- First execution of _setLoginToken:
- Calls _removeTokenFromConnection (no-op since no token yet)
- Actually sets the token on the connection
- Sets self._userObservesForConnections[connection.id] to null and
defers some work.
- Second execution of _setLoginToken:
- Calls _removeTokenFromConnection. It sees the null in
self._userObservesForConnections[connection.id] and deletes it,
which is supposed to signal to the first deferred thing that
it got overridden.
- Actually sets the token on the connection (again)
- Sets self._userObservesForConnections[connection.id] to null and
defers some work.
- Hold on a sec... doesn't that look exactly like what the first
one was expecting to see before we deleted it to send a signal?
Hmm...
- The Meteor.defer from the first call runs:
- It starts an observe
- Then it runs this check:
if (self._getAccountData(connection.id, 'loginToken') !== newToken ||
!_.has(self._userObservesForConnections, connection.id)) {
Well, hmm. The login token is the login token we're trying to set.
And self._userObservesForConnections[connection.id] is still that
null that we were expecting! I guess we weren't overridden by anything...
- It saves the observe into self._userObservesForConnections[connection.id]
- The Meteor.defer from the second call runs:
- It starts an observe
- Then it runs that check again. The token is still the token we want,
and there is something in self._userObservesForConnections[connection.id],
so no need to bail out... uhoh.
- But! The thing in self._userObservesForConnections[connection.id]
is not null! So we throw.
So two issues: first, we're throwing (from a defer, so a stack trace
prints). But more importantly: the second observe never gets stopped!
Resource leak!
This commit fixes this by ensuring that the sentinel used by
_setLoginToken to mean "I'm trying to set up an observe here" looks
different between the two calls to _setLoginToken. This is roughly what
the `self._getAccountData(connection.id, 'loginToken') !== newToken`
part was trying to accomplish, but it failed if both calls set the same
token. Instead of using null as our only sentinel, just use a number
that differs between subsequent calls!
(We could probably work around this particular issue by making
_setLoginToken bail out immediately if the login token isn't changing,
but you could still hit this issue with three rapid calls of "set A, set
B, set A".)
(Why do we care about this edge case? Turns out that
the (closed-source) meteor-accounts server does something a little
strange in its login handler where it actually calls
`Meteor.call('login')` again and tries to carefully massage its return
value into a login handler return value. (This wasn't the best design!
We should have just added an API to accounts-password for it to run
directly instead, or some other hook.) This means that each nested
version of the login method calls _setLoginToken with the same value in
rapid succession.)
Reviewed at https://rbcommons.com/s/meteor/r/45/
