[Bug] Environment weather fetch cannot persist rows because Prisma enum name does not match migrated PostgreSQL type

[lutzkind]

Summary

The Environment module can show a valid configured home location but remain permanently at 0 days recorded because every environment-fetch job fails when Prisma tries to write the source enum.

The database migration creates the PostgreSQL enum as:

public.environment_location_source

but the Prisma schema declares EnvironmentLocationSource without an enum @@map, so the Prisma 7 PostgreSQL driver adapter generates a cast/reference to:

public.EnvironmentLocationSource

That type does not exist. The fetch succeeds far enough to reach the database upsert, then the entire transaction fails and no environment_contexts rows are stored.

Affected version

Confirmed on a self-hosted server running:

• HealthLog v1.32.31
• Prisma client 7.8.0
• PostgreSQL 16

Current main still has the same unmapped enum declaration, so this is not limited to the deployed patch version.

User-visible reproduction

1. Enable/open the Environment module.
2. Configure a valid home location and effective date.
3. Wait for the immediate/default fetch or the nightly environment job.
4. Open the native Environment screen.

Actual behavior

The screen shows:

Home location
<configured location>

Weather data
0 days recorded

No weather data ever appears.

Expected behavior

Recent eligible days should be fetched from Open-Meteo, persisted in environment_contexts, and reflected in the overview count and downstream environmental correlations.

Confirmed production evidence

The account had:

• a valid coarse home latitude/longitude;
• an IANA home timezone;
• homeSince set to 20 July 2026;
• the Environment module enabled by the normal default-on module policy.

Read-only database queries showed:

environment_contexts rows: 0
environment_travel_locations rows: 0

The overview endpoint correctly returned context_days = 0; this is not an iOS-only display error.

The nightly pg-boss job ran at the documented 02:10 Europe/Berlin schedule and retried three times. Each attempt failed with PostgreSQL error 42704:

[pg-boss] [environment-fetch] failed Error [DriverAdapterError]:
type "public.EnvironmentLocationSource" does not exist

The repeated failure occurred before any row could be committed.

Migration/schema mismatch

Migration 0217_v125_environmental_context creates:

CREATE TYPE "environment_location_source" AS ENUM ('HOME', 'TRAVEL');

Migration 0219_v125_env_home_since later adds:

ALTER TYPE "environment_location_source" ADD VALUE IF NOT EXISTS 'DEVICE';

The applied production database therefore contains:

public.environment_location_source
  HOME
  TRAVEL
  DEVICE

and environment_contexts.source uses that exact type.

Current prisma/schema.prisma declares:

enum EnvironmentLocationSource {
  HOME
  TRAVEL
  DEVICE
}

with no mapping to the migrated snake-case PostgreSQL type.

The EnvironmentContext model itself is correctly mapped to environment_contexts, but its enum is not.

Root cause

A schema/migration naming drift:

• physical PostgreSQL enum: environment_location_source
• logical Prisma enum: EnvironmentLocationSource
• missing Prisma enum mapping

With the current Prisma PostgreSQL adapter, the upsert references the logical enum type name and PostgreSQL rejects it because only the snake-case type exists.

Smallest general fix

Map the Prisma enum to the existing database type and regenerate the client:

enum EnvironmentLocationSource {
  HOME
  TRAVEL
  DEVICE

  @@map("environment_location_source")
}

This preserves existing databases and future installs without renaming a live enum type or rewriting the column.

An alternative would be a migration that renames the physical PostgreSQL enum to "EnvironmentLocationSource", but mapping Prisma to the already-established snake-case database contract is smaller and less disruptive.

Recovery behavior

After the schema/client fix is deployed:

• the existing nightly seven-day lookback should automatically retry and fill recent eligible dates;
• an explicit backfill should work for the permitted range;
• no manual deletion or recreation of the home location should be necessary.

Regression tests

Migrated-database integration

Create a real PostgreSQL test database by applying the production migrations, then run an EnvironmentContext create/upsert using each source value:

• HOME
• TRAVEL
• DEVICE

This must be a database integration test, not only a mocked Prisma test, because mocks cannot detect physical enum-name drift.

Environment job

• Configure a home location with an eligible effective date.
• Stub Open-Meteo with one or more daily observations.
• Run handleEnvironmentFetch().
• Assert stored > 0 and rows exist in environment_contexts.
• Re-run and verify idempotent upsert behavior.

API/UI

• GET /api/environment reports the stored day count and latest date.
• Native/web environment surfaces stop showing 0 days recorded after successful storage.

Migration-contract guard

Add a schema/migration consistency check for mapped PostgreSQL enums so a Prisma logical enum name cannot silently drift from its physical database type again.

Scope

This is not caused by Open-Meteo availability, the home effective-date rule, module configuration, or the native UI. The upstream fetch reaches the persistence path; the PostgreSQL enum lookup fails during the database write.

[MBombeck]

Confirmed exactly as you described it, @lutzkind, and I checked the wider shape before replying: the schema declares 49 enums, and this is the only one without a @@map. Every other one maps to its snake_case database type. So the generated client refers to a type that does not exist, the upsert throws, the transaction rolls back, and the module reports "0 days recorded" indefinitely.

Which means the Environment module has never been able to persist anything, for anyone, since it shipped. Your report is the first time that surfaced.

The one-line fix is not the interesting part. Three things are going in with it:

The job's failure has to become visible. A scheduled job that throws on every single run and produces a screen reading "0 days recorded" is exactly the failure mode where nothing is wrong with the code's knowledge — it knows perfectly well that it failed — and everything is wrong with what reaches a person. That is the same class as the glucose constraint you found, and it deserves the same treatment.

A guard so the class cannot recur: one enum out of forty-nine drifting from what the migrations created is precisely what a structural test is for. Model and column mappings are being checked the same way, in case anything else has drifted quietly.

And an honest answer on the backlog, which I do not have yet: whether past days can be fetched retroactively from the weather source or whether that history is simply gone. I will say which when I know.

Thank you for tracing it to the type name rather than stopping at "the module does not work". That is the difference between a two-minute diagnosis and a long afternoon.

I will report back here when it ships. Leaving this open until you have had a chance to confirm.

[MBombeck]

Fixed, @lutzkind, and your diagnosis was right down to the type name. The reported 42704 is reproduced in a test now: reverting the map and regenerating the client makes it fail with type "public.EnvironmentLocationSource" does not exist.

Three things worth reporting back.

No migration was needed, and adding one would have been wrong. I checked with migrate diff before and after rather than assuming. Before the fix it wanted to drop and recreate the source column because the type names disagreed; after, that entry is gone and the rest of the diff is identical. The database was never the side that drifted. Renaming a live type to match a datamodel typo would have rewritten an enum and a column for nothing.

Your history is recoverable. The days were never written, and the weather source is queried by date range, so nothing is lost. After you update, the nightly job's seven-day lookback fills the last week by itself. For anything older there is a Backfill button in Settings → Environment; it is capped at 730 days per run, so a multi-year history takes a few passes. Two limits worth knowing: days before your home location's effective date are deliberately skipped, because attributing past days to your current home would be inventing weather you did not have, and the archive feed lags real time by a few days. You do not need to delete or re-create the location.

The visibility half. The throw was reaching an unnamed counter on the admin status page and a log line in the container, and nothing else. That is now read from what the queue already records: the admin page names each failing queue with a count and the last error, and the Environment response carries your own failed runs so a zero day count is never left standing on its own. It needed no change at the thirty-odd places that record an error — a visibility fix you have to remember to apply at each call site is the same failure one level up.

And a guard, since one enum out of forty-nine drifting is exactly what a structural test is for: every enum must declare its mapping and land on a type the migrations actually create, checked against a real migrated database along with every table and column name. Nothing else has drifted.

Thank you for this one. A module that has never once worked, for anybody, is the hardest kind to notice.

[MBombeck]

Live in v1.33.0, @lutzkind.

You found something worse than a broken module. One declaration in 49 was missing the line that maps it to the database, so every write referred to a type that does not exist. The Environment module had never once saved a row, for anyone, since it shipped.

The part that stayed with me is the second half. The nightly job failed every night and recorded that failure faithfully, and no code anywhere reads a failed job. So it was not that nobody noticed, it is that noticing was not wired to anything. Both halves are fixed: the module writes now, and a failing background job names itself on the admin page and on the screen it affects.

Past days can be fetched from the weather source, so nothing is lost to the gap. The nightly job fills the last week by itself and the backfill button covers the rest.

Two of the defects in this release were found because someone outside the project read the code and said what was wrong. This was one of them. Thank you.

[MBombeck]

Short follow-up, @lutzkind, because "shipped" and "working" are two different claims and I wanted the second one.

I checked the production database today. The environment_contexts table holds rows again, the most recent written by last night's job. Before the fix not a single insert could commit; every one of them died on the missing type. So the module is not just patched, it is demonstrably storing what it collects.

Whenever you get to it, the thing worth checking on your own instance is that the stored-days count on the environment card is climbing, and that the nightly job no longer shows up as failing on the admin page. If either still looks wrong for you, this stays open.