Disappearing collections in the UI for one environment

Feature(s) impacted

The collections in the UI

Observed behavior

I have added 2 new collections to the UI. Deployed them to our reference environment on ForestAdmin. So far so good. They appear on the FA reference environment and the development one. I create a new branch on the development environment (forest branch …), making sure that it’s layout is equal to the one on production. The forestadmin-schema.json is the same on all our servers.

Now, after a while the two collections disappear from the UI in the ForestAdmin development environment. If I press Edit Layout, I also confirm that they are not there (hidden). I am also not able to access them by manipulating the URL. Meanwhile, on the reference environment everything works fine (the two new collections are there) and I don’t see this behaviour,

Expected behavior

I expect the two collections to not disappear unexpectedly from the UI.

Failure Logs

None found.


Please provide in this mandatory section, the relevant information about your configuration:

  • Project name: jurata
  • Team name: jurata
  • Environment name: Production, Development
  • Agent type & version: Chrome and “forest-express”: “^7.4.0”, “forest-express-mongoose”: “^7.7.1”,
  • Recent changes made on your end if any: adding the two collections: to all our servers, I deployed a correct version of forestadmin-schema.json (which includes these collections), and also all the other required files under models/, routes/, forest/.

Hi, @David_Roegiers,

When comparing production to dev, we can see this:

  • dev is missing collections “le*Pr*Or*” and also collection “cl*

Collections, but also underlying models are missing these two objects.
It means the dev forest schema was last sent without the related tables.

The schema history gives these versions:

  • 20/06/2022 11:18:46 - “le*Pr*Or*” and “cl*” models are not here
  • 20/06/2022 11:17:26 - “le*Pr*Or*” and “cl*” models are here
  • 19/06/2022 00:24:18 - “le*Pr*Or*” and “cl*” models are not here
  • 19/06/2022 00:23:47 - “le*Pr*Or*” and “cl*” models are here
  • 19/06/2022 00:22:43 - “le*Pr*Or*” and “cl*” models are not here
  • 19/06/2022 00:21:54 - “le*Pr*Or*” and “cl*” models are here
  • 18/06/2022 23:02:30 - “le*Pr*Or*” and “cl*” models are not here
  • 18/06/2022 23:01:17 - “le*Pr*Or*” and “cl*” models are here
  • 18/06/2022 23:00:50 - “le*Pr*Or*” and “cl*” models are not here
  • 18/06/2022 23:00:17 - “le*Pr*Or*” and “cl*” models are here

This indicates the dev environment is restarting and sending two different versions alternatively.
This should not happen.
Are you sure you have only one dev project on your laptop (using the dev secret-key)? It seems you have two dev projects that restart one after the other.

In another hand, the dev environment is restarting about 900 times a day (it sends the forest schema when it starts, but most of the time nothing has changed) which seems to be a lot.
Sometimes developers restart a lot their environment because they are coding on it, but in this case, restarts regularly day and night. Are you a robot :smiley: ?


Hi @Sliman_Medini

Thanks for looking into my case.

I don’t think I’m a robot - yet I’m not entirely sure, this might just be a very convincing simulation. #matrix

The dev environment exists in two places :

  • My laptop. I don’t run it often, and it hasn’t been running since Sunday morning.
  • A server in the cloud, it does not seem to restart … Just checked the logs.

Very strange. Do you have more information about the behaviour you mentioned before?

Hi, @David_Roegiers,

Being not sure is a human property, but, how to know? :slight_smile:

You should not have the same secret key for two environments.
It drives errors from the forest point of view because the secret key is the environment identifier.

I shared with you in PM two screens:

  • The first is “apimap” call list, each line match a call to Forest with your environment secret key, in order to synchronize your schema. This is done each time your server start.
  • The second screen is the “refresh” call list, each “refreshRenderingCache” line match a “apimap” call, and a refresh is made (otherwise, nothing is done since nothing changed)

Thanks for sharing this - I have found the issue now on our end: some naughty service has been indeed restarting continuously somewhere in our infra … Apologies for the many unnecessary requests to your servers.

1 Like