Upgrading from v7 -> v9

Feature(s) impacted

Upgrading from V7 → V9

Observed behavior

Test environment is on V7

Expected behavior

Test environment upgraded to V9

Context

  • Project name: GroupfinderWithVolJourny
  • Team name: Operations
  • Environment name: Test
  • Database type: SQL Server
  • Recent changes made on your end if any: None

And, if you are self-hosting your agent:

  • Agent technology: nodejs - Azure
  • Agent (forest package) name & version (from your .lock file): “forest-express-sequelize”: “^9.3.9”

We have a production environment running in V9 that was performed by an incumbent agency, and a test environment that is running on V7. We host both agents in NodeJS on Azure, and both are (I believe) upgraded to V9, because they both have this in the package.json file:
“forest-express-sequelize”: “^9.3.5”,

However, the forest admin environment still shows V7, and I’m not sure what I need to do within forest-cli to alter this. I can log in to the forest-cli and list the environments, but not sure on next steps.

I can see references to a .forestadmin-schema.json file - I’ve changed my forest-express-sequelize version to be 9.3.5 and pushed to my agent, but forest admin’s environment list still shows the environment as v7.

We don’t have a development environment as such, as we’ve inherited this project, we only have a codebase for the agent which is in Azure devops, and the two Forest Admin environments for Production and Test.

Grateful for any help!

Thanks,

Karl

Hello @Karl and welcome to the community !

From what I can see, the last time the .forestadmin-schema.json file was pushed from your Test environment dates from 2023, which explains why your environment is still flagged on v7.

Could you share the startup logs from your agent, it should contain information as to why the schema is not sent. Namely speaking of the var env FOREST_DISABLE_AUTO_SCHEMA_APPLY which does exactly as its name suggests.

Hi,

Thanks very much for getting back to me so quickly!

My startup logs look like this:

2025-04-01T11:50:24.493211857Z    _____                               
2025-04-01T11:50:24.493263425Z   /  _  \ __________ _________   ____  
2025-04-01T11:50:24.493267295Z  /  /_\  \\___   /  |  \_  __ \_/ __ \ 
2025-04-01T11:50:24.493270067Z /    |    \/    /|  |  /|  | \/\  ___/ 
2025-04-01T11:50:24.493272665Z \____|__  /_____ \____/ |__|    \___  >
2025-04-01T11:50:24.493275655Z         \/      \/                  \/ 
2025-04-01T11:50:24.493278617Z A P P   S E R V I C E   O N   L I N U X
2025-04-01T11:50:24.493281036Z 
2025-04-01T11:50:24.493283297Z Documentation: http://aka.ms/webapp-linux
2025-04-01T11:50:24.493285689Z NodeJS quickstart: https://aka.ms/node-qs
2025-04-01T11:50:24.493288040Z NodeJS Version : v20.18.3
2025-04-01T11:50:24.493290453Z Note: Any data outside '/home' is not persisted
2025-04-01T11:50:24.493292895Z 
2025-04-01T11:50:49.957854196Z Starting OpenBSD Secure Shell server: sshd.
2025-04-01T11:50:50.058582637Z WEBSITES_INCLUDE_CLOUD_CERTS is not set to true.
2025-04-01T11:50:50.439984563Z Updating certificates in /etc/ssl/certs...
2025-04-01T11:51:35.531980502Z rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
2025-04-01T11:51:36.669837287Z 2 added, 0 removed; done.
2025-04-01T11:51:36.669872370Z Running hooks in /etc/ca-certificates/update.d...
2025-04-01T11:51:36.669876320Z done.
2025-04-01T11:51:36.669878901Z CA certificates copied and updated successfully.
2025-04-01T11:51:38.205555988Z Starting periodic command scheduler: cron.
2025-04-01T11:51:38.205587842Z Could not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2025-04-01T11:51:38.205591602Z Could not find operation ID in manifest. Generating an operation id...
2025-04-01T11:51:38.205594792Z Build Operation ID: 593547d8-bfc7-4c0c-81e8-6b5ddc7ac454
2025-04-01T11:51:41.062175660Z Environment Variables for Application Insight's IPA Codeless Configuration exists..
2025-04-01T11:51:41.081693602Z Writing output script to '/opt/startup/startup.sh'
2025-04-01T11:51:41.412608993Z Running #!/bin/sh
2025-04-01T11:51:41.412633770Z 
2025-04-01T11:51:41.412637136Z # Enter the source directory to make sure the script runs where the user expects
2025-04-01T11:51:41.412639972Z cd "/home/site/wwwroot"
2025-04-01T11:51:41.412642603Z 
2025-04-01T11:51:41.412644910Z export NODE_PATH=/usr/local/lib/node_modules:$NODE_PATH
2025-04-01T11:51:41.412647392Z if [ -z "$PORT" ]; then
2025-04-01T11:51:41.412649919Z 		export PORT=8080
2025-04-01T11:51:41.412652571Z fi
2025-04-01T11:51:41.412654972Z 
2025-04-01T11:51:41.412657208Z npm start
2025-04-01T11:51:58.316717476Z npm info using npm@10.8.2
2025-04-01T11:51:58.316753478Z npm info using node@v20.18.3
2025-04-01T11:52:43.198367892Z 
2025-04-01T11:52:43.208554151Z > groupfinderwithvoljourny@0.0.1 start
2025-04-01T11:52:43.208571641Z > node ./server.js
2025-04-01T11:52:43.208574771Z 

I can’t spot anything in there that might point toward the env variable you mentioned.

I don’t have anything by that name in the .env file either.

Do you confirm that the .forestadmin-schema.json file contains liana_version with the expected version of 9.3.9 ?

1 Like

Hi,

The package.json file shows “forest-express-sequelize”: “^9.3.5”, but the .forestadmin-schema.json file shows “liana_version”: “7.0.3”!

I thought I’d updated that value, but might’ve had to revert it, as I think it might’ve broken the agent.

I’ve read that file should update automatically though, so am I missing a step?

The schema generation will only happen if your NODE_ENV variable is unset or NODE_ENV=dev | NODE_ENV=development.

The generation is done on agent startup, and will be sent to our server if FOREST_DISABLE_AUTO_SCHEMA_APPLY is not set or false

You’ve hit the nail on the head there - Our NODE_ENV was set to ‘staging’. I changed it to ‘development’, restarted the agent, and the .forestadmin-schema.json file updated to show the correct 9.3.5 version number for liana_version.

The correct version is now showing in the environments list, but within Forest Admin, I now get a ‘cannot reach your data’ error, though the rest of the environment variables including the DB connection string, are all the same. I’ve verified the DB still exists and is contactable with the existing credentials - Is there anything obvious I should investigate?

Thanks for all your help so far!

Karl

2 Likes

Happy to help !

It seems like you’re facing CORS issues now, could you confirm by opening your network tab in your browser and share the content of the failing calls, both request and response headers if you do have a response.

1 Like

That’s just the pointer I needed thank you! Not sure how the allowed origin got wiped on that agent, but I’ve re-established it, and can now see our data.

Thanks again for all your help!

Karl

1 Like