Using preview 23, sometimes when a string is changed through the Web UI, any call to mf() on the server doesn't pick up the changes and uses the string cached in mfPkg.compiled.
I've tracked down the bug and it looks like this happens if a string has an mtime less than the updatedAt of its language at the moment of the change. Doing some debugging using node inspector on the server, the changed function in ObserveFrom never gets triggered:
|
}, changed: function(doc) { |
I guess this is because the actual string is not observed for changes since its not observed by the query, which is constrained by the mtime calculated previously
|
var query = {mtime: {$gt: mtime}}; |
For now, as a workaround, I'm adding an observer for the whole collection in /lib at the moment of initialization and copying the added/changed functions from msgfmt.js, but of course that's suboptimal and not really sure if it could have any side effect.
Using preview 23, sometimes when a string is changed through the Web UI, any call to mf() on the server doesn't pick up the changes and uses the string cached in mfPkg.compiled.
I've tracked down the bug and it looks like this happens if a string has an mtime less than the updatedAt of its language at the moment of the change. Doing some debugging using node inspector on the server, the changed function in ObserveFrom never gets triggered:
meteor-messageformat/packages/core/lib/msgfmt.js
Line 125 in 7b1c8af
I guess this is because the actual string is not observed for changes since its not observed by the query, which is constrained by the mtime calculated previously
meteor-messageformat/packages/core/lib/msgfmt.js
Line 110 in 7b1c8af
For now, as a workaround, I'm adding an observer for the whole collection in /lib at the moment of initialization and copying the added/changed functions from msgfmt.js, but of course that's suboptimal and not really sure if it could have any side effect.