Admin functions

hello, when I try to connect to the admin interface, I get a blank screen. I can’t do updates, for example, even though I’m an admin.
What should I do?
Thanks for helping.
Muriel

1 Like

You might try safe-mode. You might also do well to do a command line upgrade.

3 Likes

Update: I did a proper bootstrap, destroy, start with a 2-container setup and now the reported version numbers are updated and the Admin UI is rendering again.

The rest of the post remains for posterity.


I’m experiencing what may be a similar issue. The Admin interface loads, but only displays the tabs at the top and the main content section is blank:

Browser Console Logs

Reviewing the browser console logs, I see errors like:

[Error] Error: VM BUG: Target must be set before attempting to jump
vendor.xxxxx-xxxx.js
Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
Error Stack
[Error] Error: VM BUG: Target must be set before attempting to jump
	b (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:131956)
	evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:69428)
	_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
	execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
	rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
	tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
	_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
	_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
	_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
	invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
	flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
	flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
	_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
	end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:156653)
	_runExpiredTimers (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:160801)
[Error] Unhandled Promise Rejection: Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
	(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1310)
	h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1311)
	(anonymous function) (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:3065)
	h (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:1375)
	requireModule (vendor.6f1929e16c84d825f1e134b0a5a6bf6d-ed21b08557694a2386531fb8b5bd479da7fe4ec9cffd9278c49f382c5e7bc3a4.js:1:599)
	_extractDefaultExport (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:269780)
	resolveOther (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266326)
	resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:105:266888)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262092)
	resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262185)
	resolve (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:262275)
	c (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:260192)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:258815)
	getRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:56849)
	fetchRoute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:267571)
	_getQPMeta (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63399)
	_hydrateUnsuppliedQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:64113)
	_prepareQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:63271)
	normalizeQueryParams (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38898)
	_generateURL (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:111:38990)
	eA (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:202925)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49065)
	X (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:140358)
	T (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:49044)
	eM (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:80191)
	flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:79868)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:70930)
	evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:65312)
	evaluateSyscall (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111047)
	evaluateInner (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110609)
	evaluateOuter (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:110528)
	next (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121496)
	_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:121359)
	handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:112232)
	handleException (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:114799)
	throw (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111583)
	evaluate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:68993)
	_execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111383)
	execute (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:111253)
	rerender (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:115153)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252217)
	tx (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:105883)
	_renderRoots (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252117)
	_renderRootsTransaction (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252504)
	_revalidate (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:252982)
	invoke (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:153517)
	flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:152599)
	flush (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:154477)
	_end (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:159527)
	(anonymous function) (chunk.6994431508d4f7ecb4c3.d41d8cd9.js:119:155980)

Upgrade Process (2-container)

I originally started experiencing the issue after trying to complete the upgrade from within the Discourse Admin UI where I was shown that I needed to update the Docker Manager first.

After updating the Docker Manager, I started experiencing that issue, so I SSH’ed into the box and did a manual (2 container) update for just web_only:

cd /var/discourse
git pull
./launcher bootstrap web_only
./launcher stop web_only && ./launcher start web_only
           ^^^^
    ⚠️ This is wrong! Use destroy per below. ⚠️

Curiously, the /about.json path still shows I’m running 3.4.0.beta4-dev which is what I thought I started from as the original email was for an upgrade from 3.4.0.beta4-dev to 3.5.0.beta1.

I double checked the git log and it seems like at least the discourse_docker is on the latest commit 3715498fc188d60c0b579443383c4e973cf26f59 at the time of writing this.

Safe-Mode Works

I wasn’t aware of safe mode, but apparently the issue doesn’t occur if I disable ALL client side plugins.

Disabling only unofficial client-side plugin customizations does not resolve the issue as I tried each combination to narrow things down.

Option Result
no_unofficial_plugins :x:
no_plugins :white_check_mark:
no_themes :x:

Disabling docker_manager doesn’t help

I tried commenting out the docker_manager plugin under hooks/after_code, then rebuilding the web_only container + stop && start, but the client side error message noted above still remains.

It does introduce another error message which visiting the Admin page of this.class.create is not a function, but perhaps that’s expected with the underlying docker_manager plugin disabled for this test:

loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/lib/decorators` imported from `discourse/plugins/docker_manager/discourse/routes/update`
    at loader.js:247:1
    at h (loader.js:258:1)
    at u.findDeps (loader.js:168:1)
    at h (loader.js:262:1)
    at requireModule (loader.js:24:1)
    at f.get (composer.js:874:1)
    at push.98673._extractDefaultExport (composer.js:874:1)
    at push.98673.resolveOther (composer.js:874:1)
    at push.98673.resolve (composer.js:874:1)
    at n.i [as getRoute] (upload-debugging.js:25:1)
    at p._getQPMeta (upload-debugging.js:25:1)

index.js:78 Uncaught TypeError: this.class.create is not a function
    at n.i [as getRoute] (upload-debugging.js:25:1)
    at p._getQPMeta (upload-debugging.js:25:1)

Again, using safe mode with no_plugins works around the issue temporarily.

I was going from memory on the commands for the 2 container minimal downtime update and apparently my memory can’t be trusted! :flushed:

After using the proper command to destroy and then start the new container after bootstrapping, I see the versions are updated and the Admin Interface is working as expected.

Did you upgrade the data container? You should, but first, see PostgreSQL 15 update. Or, if you really hate reading, just run ./laumcher rebuild data twice and you should be OK. Then you’ll need to destroy, start the web container (otherwise it’ll look for the old data container that you will have destroyed).

Not yet, but thanks for looking out!

I was already considering setting up a new beefier server, so I was just doing some research to see if I could backup from Discourse 3.5 + PG13 and then restore on Discourse 3.5 + PG15 on a different host.

I don’t love extended downtime and in the past I temporarily set the community read-only and did a backup/restore across server instances and it was effectively zero downtime (aside from the read only period of course)… so I figured I would research / test to see if it works across PG versions.

Otherwise I’ll just bite the bullet and do the PG15 upgrade first before the server migration. :slight_smile:

1 Like

It does. It’s probably time to upgrade your OS anyway. Just spin up a new server and restore your backup.

1 Like

I’ve got exactly the same issue. thanks for helping. My webmaster Benjamin will read you.
Muriel

this what happened to me. spinning up a new server and restoring from backup was the only option.
He is to the point. And don’t waste your time debugging. this advice gets you going in no time.

I ended up doing the backup and restore and it worked as expected.


For reference in case anyone else runs into a similar issue…

I ran into a bit of an issue at first as the restore process apparently calls the uploads:migrate_to_s3 internally and it was getting hung up.

2025-02-26 00:24:16] Migrating the database...
[2025-02-26 00:24:24] 
[2025-02-26 00:24:24] Reconnecting to the database...
[2025-02-26 00:24:24] Reloading site settings...
[2025-02-26 00:24:24] Disabling outgoing emails for non-staff users...
[2025-02-26 00:24:24] Disabling readonly mode...
[2025-02-26 00:24:24] Clearing category cache...
[2025-02-26 00:24:24] Reloading translations...
[2025-02-26 00:24:24] Remapping uploads...
[2025-02-26 00:24:24] Restoring uploads, this may take a while...
[2025-02-26 00:25:09] EXCEPTION: 12 of 12208 uploads are not migrated to S3. S3 migration failed for db 'default'.
[2025-02-26 00:25:09] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:73:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:383:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:354:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-02-26 00:25:09] Trying to rollback...
[2025-02-26 00:25:09] Rolling back...
[2025-02-26 00:25:10] Cleaning stuff up...

I ended up running some SQL queries in the data container to see if I could figure out what was going on.

./launcher enter data
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%s3%';

That just returned some standard built-in items from Discourse, so I tried the reverse:

SELECT url from uploads where url LIKE '%s3%' limit 10;

That gave me a bunch of matches in the format:

  • //{my-bucket-name}.s3.dualstack.us-east-2.amazonaws.com/original/2X/5/{image-id}.jpeg

So then I tried a query to get everything except items which matched that s3.dualstack host and I found that there were 12 old entries using a slightly different format (matching the number that failed from prior restore log failure).

  • //{my-bucket-name}.s3-us-east-2.amazonaws.com/{file-path}.jpeg

When I checked for the existence of those files in the actual bucket, they didn’t exist, so I ended up deleting them with something like:

DELETE FROM uploads where url LIKE '%{my-bucket-name}.s3-us-east-2.amazonaws.com%';

After that, the backup and restore worked as expected!

PS. Don’t forget to re-enable emails after you restore the backup!

/admin/site_settings/category/all_results?filter=disable_email
1 Like