# knowbase

> Verified, source-backed answers to concrete engineering failures. Every entry states the error, the root cause, the fix, the versions it applies to, and the primary sources that prove it.

Every entry is a Knowledge Object: one concrete failure, its root cause, the fix, the
versions it applies to, the primary sources that back it, and the date it was last
checked against them. Entries also state what they do *not* apply to.

Any entry is available as JSON, Markdown, or plain text by appending an extension:
https://knowbase.sh/k/<slug>.json · .md · .txt

License: CC-BY-4.0. Attribution is the canonical URL of the entry.

## api

- [CORS error: No Access-Control-Allow-Origin header on the response](https://knowbase.sh/k/cors-no-access-control-allow-origin): The browser blocked the response because the server did not say the requesting origin is allowed. Nothing about the frontend can fix it — the header has to come from the server, and the browser deliberately hides the reason from JavaScript, so the console is the only place the actual rule violation is named. (confidence: high, verified 2026-08-07, 3 sources)
- [Stripe API returns 429 Too Many Requests](https://knowbase.sh/k/stripe-429-rate-limit): Stripe returns 429 for two unrelated reasons: you exceeded a rate or concurrency limit, or you hit an object lock timeout. The Stripe-Rate-Limited-Reason header tells you which, and only one of them is fixed by slowing down. (confidence: high, verified 2026-08-07, 3 sources)

## database

- [Npgsql PostgresException 22001: value too long for type character varying(n)](https://knowbase.sh/k/npgsql-22001-string-data-right-truncation): PostgreSQL rejects the write because a string exceeds the column's declared length. The error names the type and the limit but not the column, so the practical work is identifying which parameter overflowed — and PostgreSQL counts characters, not bytes. (confidence: high, verified 2026-08-07, 4 sources)
- [PostgreSQL error 53300: sorry, too many clients already](https://knowbase.sh/k/postgres-53300-too-many-connections): Every connection slot is taken. Raising max_connections is the obvious move and usually the wrong one — each slot costs memory whether it is working or idle. The real question is why so many connections exist, and the answer is almost always pool size multiplied by instance count. (confidence: high, verified 2026-08-07, 3 sources)

## framework

- [React hydration failed: server HTML did not match the client](https://knowbase.sh/k/nextjs-react-hydration-mismatch): Hydration compares the server-rendered HTML against the first client render and fails when they differ. The cause is almost always one of three things: HTML the browser silently restructured, rendering logic that branches on the environment, or a value that changes between the two renders. (confidence: high, verified 2026-08-07, 4 sources)
- [React re-render loop: Too many re-renders or Maximum update depth exceeded](https://knowbase.sh/k/react-infinite-render-loop): A state update is triggering a render that triggers the same update again. The two error messages point at different halves of the problem — one means state is set during render, the other means an Effect is updating a value it also depends on — and neither names the component responsible. (confidence: high, verified 2026-08-07, 3 sources)

## kubernetes

- [Container terminated with exit code 137 and reason OOMKilled](https://knowbase.sh/k/container-exit-code-137-oomkilled): Exit code 137 means the process received SIGKILL (128 + 9). In Kubernetes it almost always means the container breached its own memory limit and the cgroup OOM killer ended it — a different failure from the node running out of memory, which evicts the pod instead. (confidence: high, verified 2026-08-07, 4 sources)
- [Kubernetes pod fails with CreateContainerConfigError](https://knowbase.sh/k/kubernetes-createcontainerconfigerror): The image pulled fine, but the kubelet cannot assemble the container's configuration: a referenced ConfigMap or Secret does not exist, or exists without the key the pod asks for. The pod stays in Waiting and no container is ever created. (confidence: high, verified 2026-08-07, 3 sources)
- [Kubernetes pod stuck in CrashLoopBackOff](https://knowbase.sh/k/kubernetes-crashloopbackoff): CrashLoopBackOff is not an error in itself — it is the kubelet waiting between restarts of a container that keeps exiting. The exit code and reason on the previous container instance identify the actual failure; the backoff only controls how long you wait to see it again. (confidence: high, verified 2026-08-07, 4 sources)
- [Kubernetes pod stuck in ImagePullBackOff or ErrImagePull](https://knowbase.sh/k/kubernetes-imagepullbackoff): The kubelet cannot pull the image, so the container never starts. ErrImagePull is the first failure and ImagePullBackOff is the wait between retries — neither says why. The registry's own error text, printed in the pod's Events, is what identifies the cause. (confidence: high, verified 2026-08-07, 4 sources)

## Optional

- [Full corpus as Markdown](https://knowbase.sh/llms-full.txt): every entry concatenated, for a single fetch
- [Method](https://knowbase.sh/about): how entries are produced, sourced, and rated