Refactor location detail endpoints to use website_data cache

[jbeard4]

Motivation

• Reduce heavy multi-table joins on the location detail endpoints by serving precomputed JSON stored in the existing website_data table.
• Ensure write operations update a cached JSON representation so GET /locations/:locationId and GET /locations-by-slug/:slug can be fast and avoid expensive queries.

Description

• Added a WebsiteData Sequelize model at src/models/website-data.js to represent the existing website_data table.
• Added src/services/location-website-data.js which centralizes building the full location detail payload, parsing/storing JSON into website_data, getWebsiteDataByLocationId, getWebsiteDataBySlug, upsertWebsiteDataForLocation, and upsertWebsiteDataForService (which refreshes all locations affected by a service change).
• Updated GET /locations/:locationId and GET /locations-by-slug/:slug (in src/controllers/locations.js) to use getWebsiteDataByLocationId and getWebsiteDataBySlug respectively, with lazy backfill when cache rows are missing.
• Updated write endpoints to refresh cache after successful mutations: locations.create/update, locations.addPhone/updatePhone/deletePhone, and services.create/update/delete now call the appropriate upsertWebsiteData* functions, and slug lookup in cache supports matching the final slash-delimited segment.

Testing

• Ran npx eslint src/controllers/locations.js src/controllers/services.js src/services/location-website-data.js src/models/website-data.js and the lint check for those modified files completed successfully.
• Ran the test suite with npm test -- --runInBand and it failed in this environment due to the Node test runtime missing the fetch shim required by the installed openai package (not related to the location cache changes).

---

Codex Task

[github-actions]

Not safe to approve yet: the new website_data cache introduces behavior changes and stale-data failure modes that can break API correctness.

Blocking issues

• getInfoBySlug no longer does exact slug matching; it matches the last path segment via SQL split_part(...). This can return the wrong location when multiple slugs share the same leaf, which is a broken API behavior regression from the previous exact where: { slug } lookup.
• Cached reads (getWebsiteDataByLocationId / getWebsiteDataBySlug) trust website_data rows without validating source record existence/freshness. If upstream records are deleted or cache rows become stale, endpoints can serve outdated data instead of 404/current state.
• parseWebsiteDataRow does raw JSON.parse with no guard/rebuild path. A single malformed website_data.data value will throw and fail requests (500) rather than recovering by regenerating data, creating an avoidable availability regression.
• No tests are included for this risky cache layer (slug lookup semantics, cache invalidation/refresh on mutations/deletes, malformed cache payload handling). Given the API-path refactor, missing regression coverage is blocking.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 980f1ddfce

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Invalidate cache when organization data changes

This read path returns cached JSON unconditionally once a website_data row exists, but the commit only refreshes cache rows from locations/services mutation handlers. Organization edits (for example PATCH /organizations/:organizationId in src/controllers/organizations.js) update fields that are embedded in the location payload (organization name and derived slug), so after one cached read, GET /locations/:locationId can keep serving stale organization/slug data indefinitely.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Keep slug endpoint payload in its legacy format

The cache builder hard-codes excludeMetadata to false, and getInfoBySlug now serves this cached payload too. Previously /locations-by-slug/:slug used the excludeMetadata path (returning lastValidatedDateForLocation and omitting metadata blobs), so this change silently alters the response contract for slug lookups and can break clients that rely on the old schema.

Useful? React with 👍 / 👎.