Failed upgrade from v2.7.0.beta1 to v2.7.0.beta2

Please see this gist gist:86508bebb133a06f79fadaeba345e3d6 · GitHub

This is a stock-standard, standalone Discourse install, trying to upgrade from v2.7.0.beta1 to v2.7.0.beta2

Failure is here:

uglifyjs '/var/www/discourse/public/assets/_vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js' -m -c -o '/var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js' --source-map "base='/var/www/discourse/public/assets',root='/assets',url='/assets/'"
Parse error at _vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js:1850,34
        return Handlebars.compile(...arguments);
ERROR: Unexpected token: punc «.»
    at JS_Parse_Error.get (eval at <anonymous> (/usr/lib/node_modules/uglify-js/tools/node.js:18:1), <anonymous>:71:23)
    at fatal (/usr/lib/node_modules/uglify-js/bin/uglifyjs:394:27)
    at run (/usr/lib/node_modules/uglify-js/bin/uglifyjs:343:9)
    at Object.<anonymous> (/usr/lib/node_modules/uglify-js/bin/uglifyjs:259:5)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
rake aborted!
Errno::ENOENT: No such file or directory @ rb_file_s_size - /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
/var/www/discourse/lib/tasks/assets.rake:287:in `size'
/var/www/discourse/lib/tasks/assets.rake:287:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:178:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:278:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:269:in `each'
/var/www/discourse/lib/tasks/assets.rake:269:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:178:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:266:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

Any ideas? The site is offline as a result. Thanks.

That’s a little disturbing. Are you out of disk space or anything like that?

1 Like

Hi, nope - on the host, there’s 70GB free. Only 1% of inodes are in use.

I assumed the ‘no such file or directory’ was just a side-effect of this:

Parse error at _vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js:1850,34
        return Handlebars.compile(...arguments);
ERROR: Unexpected token: punc «.»

That file definitely exists:

root@redmine:/var/discourse# ./launcher enter app
ls -al ls -al root@xxxxx-app:/var/www/discourse# ls -al /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
-rw-r--r-- 1 discourse www-data 659907 Jan 22 04:55 /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
1 Like

I’m not sure. I just upgraded my own two self hosted instances with no issues at all.

Any unusual plugins, or third party plugins, or extensive customizations?

Thanks… absolutely no plugins or heavy customizations… it was essentially a fresh install in late 2020, just minor tweaks to settings via the admin UI for things like moderator permissions etc. Very strange.

Regretfully I didn’t take a backup before I ran the upgrade, although I have some automated ones from a couple days ago. I guess that’s my only way out of this for now… not being Ruby-minded, I’ve no idea how to figure that error out

Ah, looks like running ./launcher restart app has at least got it back online despite the database schema updates that have run. Prior to that, it was throwing a 500 error. Phew

1 Like

These are what are in the plugins dir, I am assuming they came with the core install, as I haven’t manually added any

root@redmine-app:/var/www/discourse# ls -al plugins/
total 12
drwxr-xr-x 22 discourse discourse 4096 Nov  4 04:54 .
drwxr-xr-x 56 discourse discourse 4096 Jan 22 04:55 ..
drwxr-xr-x 13 discourse discourse   43 Nov  4 04:54 discourse-details
drwxr-xr-x 16 discourse discourse   54 Nov  4 04:54 discourse-local-dates
drwxr-xr-x 20 discourse discourse   69 Jan 22 04:55 discourse-narrative-bot
drwxr-xr-x 11 discourse discourse   59 Nov  4 04:54 discourse-presence
drwxr-xr-x 19 discourse root      4096 Jan 22 04:43 docker_manager
drwxr-xr-x  4 discourse discourse   51 Sep 28 05:11 lazy-yt
drwxr-xr-x 25 discourse discourse   99 Nov  4 04:54 poll
drwxr-xr-x  8 discourse www-data   129 Nov  4 04:54 styleguide

the site theme’s a bit bust following the restart, I guess because the assets weren’t finished compiling… wonder if there’s a way to get it over the line manually…

This is the section in the vendor js file it’s complaining about:

// allow us to import this as a module
if (typeof define !== "undefined") {
  define("handlebars", ["exports"], function (__exports__) {
    // It might not be defined server side, which is OK for pretty-text
    if (typeof Handlebars !== "undefined") {
      // eslint-disable-next-line
      __exports__.default = Handlebars;
      __exports__.compile = function () {
        // eslint-disable-next-line
        return Handlebars.compile(...arguments);

  define("handlebars-compiler", ["exports"], function (__exports__) {
    // eslint-disable-next-line
    __exports__.default = Handlebars.compile;

Line 1850 (what errors) is this bit:

        return Handlebars.compile(...arguments);

Is there any temporary hack I could do here to get past it? Or is that file going to be generated each time I try the upgrade (P.S it thinks I’ve fully upgraded following the restart… but the theme is bust… wondering if I can somehow get through this step or if I’ll have to restore from backup, basically…)

1 Like

That whole section of the code comes from this file:


I guess uglify-js sees return Handlebars.compile(...arguments); as a syntax error.

What I don’t understand is how this could be unique to my install, this is all inside the Docker container…

It has come through from this commit I guess? DEV: Sync up more Ember CLI features (#11790) · discourse/discourse@83347ac · GitHub

OK - so I don’t know why, but I ran the manual upgrade process (git pull; ./launcher rebuild app) and it worked.

Lots of other activity like postgres upgrades etc came through as part of that manual upgrade.

My guess: something in that commit above, was not compatible with uglify-js or rails version or something, on the original container. It was basically an upgrade that required the ‘manual’ upgrade process.

Because the web admin interface let me upgrade docker_manager and then the discourse app itself, I assumed this would not be necessary (I know that sometimes it says an upgrade via the web admin cannot be done, and to do it manually… but that didn’t happen in this case, and probably should have…)

Thanks for your help anyway


Same thing happened for me—web upgrade failed with an “Unexpected token: punc” error, manual pull/rebuild worked.

1 Like

Got also a problem when running this update (Web upgrage) :frowning:
After executing these commands:
cd /var/discourse
git pull
./launcher rebuild app
the discourse is working, but it is not possible to enter the admin panel (/admin)

ubuntu update helped restore work


The announcement said that you’d need to do a command line rebuild. I’m not sure why the web interface didn’t know to enforce that.


Funnily enough I was just trying to use that functionality in dev and it’s not working for me … Handlebars object only has create(), not compile()though I might be barking up the wrong tree … have raised here: Adding a bespoke raw template