open-seo

This occurs when @tanstack/react-devtools 0.10.12 pulls in @tanstack/devtools-ui 0.7.1, which imports use from the SolidJS 1.9.11 server build that does not export it. Setting VITE_SHOW_DEVTOOLS=false does not help because the devtools are imported statically in src/routes/__root.tsx.

Workaround: pin @tanstack/react-devtools to the last compatible version:

"@tanstack/react-devtools": "0.10.8"

Then update dependencies:

pnpm install --no-frozen-lockfile
pnpm dev

This resolves to @tanstack/devtools-ui 0.6.0 and allows the dev server to start. The cleaner permanent fix is to load devtools with a client-only dynamic import in src/routes/__root.tsx, as implemented in commit db8bde17e245d01f9ca4ab06acaf37fe22aac361.

This is a bug in open-seo versions before v0.1.16. Block-level tags joined without whitespace (e.g., <p>one</p><p>two</p>) were parsed as concatenated text (onetwo), lowering the word count and triggering a false thin-content warning. It also affected <li>, <td>, and <br> elements and produced different content hashes for equivalent HTML. Fix: upgrade open-seo to v0.1.16 or later (fixed in commit 756538cc5). After upgrading, minified and formatted HTML yield identical word counts and content hashes, while inline markup like Open<strong>SEO</strong> still counts as one word.

This happens because the chat scroll container is pinned to the bottom on every messages update. During SAM's streaming response, updates occur for each token, so the view is pulled back down immediately. The fix is to update to the release containing the chat auto-scroll fix. As a code workaround, in SamConversation and OnboardingChatConversation, only auto-scroll when the user is already near the bottom, for example: const nearBottom = el.scrollHeight - el.scrollTop - el.clientHeight < 80; if (nearBottom) el.scrollTop = el.scrollHeight;. Do not force scrollTop = scrollHeight on every message change.

The v0.1.0 self-host image runs pnpm run build unconditionally in its startup command, rebuilding the Vite client/SSR bundles and running tsc --noEmit before serving. The fix is to use an image containing PR #120: the startup script hashes the Vite-inlined VITE_* variables plus the image build ID, caches the build output in the persistent data volume, and skips the build when both are unchanged. It also removes the runtime tsc --noEmit check. Update with docker compose pull && docker compose up -d, keeping the data volume mounted. The first start may still build; later restarts should skip it. Changing a build-relevant VITE_* variable or updating the image triggers a rebuild. If you must remain on v0.1.0, build or run the PR #120-based image; there is no built-in flag to disable the startup build in the old image.

This occurs when the scheduled rank-check cron fails before it advances nextCheckAt or creates a run row. A manual check can still succeed because it uses a different code path. The hosted issue was fixed by deploying scheduler commits f048dc3bd1c671e28aa4ceaaf22ca6663cdcb321 and eec998a76233bb33e2dddbd921fc81da2eba1e0a; database capacity was also upsized after scaling-related failures. For self-hosted instances: 1) Upgrade to a release containing those commits. 2) Search cron logs for [cron] Error processing config and the affected config ID, for example: grep '\[cron\] Error processing config' app.log | grep -E 'aea7a4ae-b6f3-4334-8196-eb9406d20dbf|845f59d5-c4cd-440f-953a-2be68374ca38'. 3) Check database CPU, connections, latency, and resource exhaustion, and upsize if necessary. 4) As an immediate workaround, use **Check rankings** manually; this updates positions but does not repair the frozen schedule. 5) After deploying the fix, requeue or contact support for any configs whose nextCheckAt remains stuck.