Production map config loading test data from dev environment on every request

[arnoldcastro5000]

Map config fetching from dev-k8s in production

File: src/pages/_app.js

Description

This was discovered while investigating periodic memory pressure on the microservices node hosting treetracker-web-map-client. The pod currently has no resource requests or limits (BestEffort QoS) and is consuming ~1008Mi on a node with 3110Mi allocatable. As part of understanding what the pod is doing on every request, I reviewed getInitialProps and found the following.

Observed behavior

getInitialProps fetches map configuration from a hardcoded dev environment URL on every page request:

const mapConfigRequest = await fetch(
  // TODO: use the ENV var, currently results in a bug with the theme editor
  // `${process.env.NEXT_PUBLIC_CONFIG_API}/config`,
  `https://dev-k8s.treetracker.org/map_config/config`,
);

It then looks for an entry named testing-config:

config = configData.find((item) => item.name === 'testing-config')?.data || defaultConfig;

What I found when checking both endpoints

• dev-k8s.treetracker.org/map_config/config — has a testing-config entry, but its data contains a localhost logo URL (http://localhost:3000/images/greenstand_logo.svg) and test navbar items
• prod-k8s.treetracker.org/map_config/config — has no testing-config entry; contains real production entries (featured-tree, featured-wallet, featured-organization, etc.)

This means production is currently applying test configuration data to every user-facing page render.

Relevance to memory pressure

Because getInitialProps runs server-side on every request, each page load:

• Opens an outbound HTTP connection to dev-k8s
• Parses and holds the full config JSON payload in memory for the duration of the request
• Under concurrent load, multiplies this across all in-flight requests simultaneously

This is not a memory leak, but it is per-request memory pressure that adds to the pod's overall RSS. On a node already running close to its memory ceiling with no limits set on any pod, this contributes to the conditions that trigger kubelet eviction of BestEffort pods.

Additionally, production availability becomes coupled to dev-k8s uptime. If dev-k8s is down or slow during a traffic spike — exactly the moment memory pressure is highest — getInitialProps will hang or error, compounding the instability.

Questions

1. Is this intentional while the theme editor bug referenced in the TODO is being resolved?
2. Was a production config entry supposed to be created in prod-k8s? If so, what should it be named?
3. Is the theme editor bug still open — and if so, is there a tracking issue?

Happy to help with the fix once the intent is clear.

@dadiorchen

[arnoldcastro5000]

Related to main issue:

Greenstand/treetracker-infrastructure#300

[dadiorchen]

@arnoldcastro5000 I think this will not cause the restart of k8s in issue 300, right?
So I want to leave this to the web map team developer to confirm and change the code in the future.