The catalog
101 lessons across 11 systems
Every one is a mechanism you operate. The line under each title is the specific misconception that lesson exists to delete.
101 lessons
"The Certificate Is Valid" Is Four Separate Checks
That certificate validation is one boolean the TLS library returns. It is four checks, they fail for different reasons, and the fourth — matching the hostname you asked for against the names in the certificate — is not part of the path validation algorithm in RFC 5280 and is not performed by every library unless the application supplies the expected name. A client that builds a perfect chain to a trusted root and never compares the hostname has proved that some real certificate authority vouched for some name, which is not the same as proving you are talking to the host you dialled.
A High PriorityClass Does Not Get Your Pod Scheduled
That a high PriorityClass is a guarantee — the scheduler will evict whatever it must to run your pod. It is not, for two separate reasons that produce the same Pending pod. First, preemption is per-node and all-or-nothing: SelectVictimsOnNode removes every eligible victim from one node and re-runs the filters, and if the pod still does not fit, that node is dropped. Free capacity spread across several nodes is never combined, so a 6-core pod on 4-core nodes stays Pending with 'Preemption is not helpful for scheduling' while the cluster holds 20 cores of batch work. Second, preemption frees space, it does not reserve it: the successful result is a nominatedNodeName written to the pod's status, which is a hint for the next scheduling cycle, not a lock, and the victims still take their full terminationGracePeriodSeconds to leave. The related belief that a PodDisruptionBudget protects a pod from preemption is also false — the scheduler prefers victims that do not violate a PDB and prefers nodes with fewer violations, but it will violate one rather than give up, which the Kubernetes documentation states as 'PodDisruptionBudget is supported, but not guaranteed'.
A nonce Is Not a Second state Parameter
That nonce is a second, redundant anti-CSRF token: state already proves the callback belongs to this browser, so the nonce is decoration you can leave unverified in the authorization code flow. state is checked at the redirect, against the browser session. nonce is checked after the token exchange, against a claim inside the ID Token. In an authorization code injection attack the attacker starts their own flow and swaps in a stolen code, so their own state comes back and matches by construction — the state check passes, and the only thing that says the ID Token describes someone else is the nonce claim the client was told it could skip.
A speed test cannot see bufferbloat, and a smaller buffer is not the fix
That bufferbloat is a hardware defect in somebody else's router, that a speed test will show it, and that the cure is a smaller buffer or a faster link. The queue is built by your own bulk flows, so a speed test — which measures exactly the quantity bufferbloat does not damage — reports the link as healthy while a video call on the same link is unusable. Shrinking the buffer trades latency for throughput and there is no single size that is right at two different link rates. And selecting fq_codel changes nothing at all unless you also shape a few percent below line rate, because until you do, the queue forms in the modem downstream of every qdisc you configured.
Adaptive Query Execution
That enabling AQE handles skew. It handles partition-size problems above two configurable thresholds; a partition that is huge because it holds one key cannot be split at all, and AQE will silently decline.
Agent Memory Poisoning
That an injection is a per-session event you recover from by starting a new chat. The write-back step is the bug: the agent summarises its own compromised turn into the memory store, and from then on retrieval — not the attacker — supplies the payload. Because the same loop keeps adding near-duplicate records around whatever query triggered it, the retrieval probability rises with every hit instead of decaying, and the record that reinfects you was authored by your own agent, so every provenance check that looks at 'where did this text come from' reads clean.
ANN Recall and the HNSW Graph
That the vector index returns the top-k nearest chunks and any bad result is the embedding model's fault. Every production vector index is approximate by construction: pgvector's hnsw.ef_search defaults to 40 and FAISS's efSearch defaults to 16, so a query for the top 100 can legitimately return 40 rows, or 4 rows once a filter matching 10% of the table is applied afterwards. Recall below 1.0 is not an error condition — there is no exception, no warning field and no partial-results flag — so a chunk that is genuinely the closest vector in the corpus can be missing from the candidate list before any ranking, reranking or fusion has run.
Approval Fatigue as a Decaying Control
That human-in-the-loop is a control with a fixed strength you can put in a threat model. It is a rate, and the rate is set by the volume of benign prompts, not by the reviewer's diligence. Every standard — OWASP, the MCP specification — recommends it, and none of them price the decay. Two things then finish the job: the prompt shows a truncated action, so the approver reviews a label rather than the arguments; and 'always allow' converts one tired decision into a permanent grant that no later prompt will revisit. Chrome's SSL interstitial, a far starker warning shown far less often, still had a 70.2% click-through rate.
Arithmetic Intensity and the Roofline
That memory-bound and compute-bound are labels attached to operations, so attention is 'the memory-bound one' and matmuls are 'the compute-bound ones'. Intensity is a property of a specific execution, not of an operation: the same weight matmul runs at 1 FLOP per byte with one token in the batch and 700 with a thousand, which is the entire reason batching works. Two consequences people miss. Batching moves the weight matmuls along the roofline but cannot move attention over the KV cache at all, because each sequence's cache is read by exactly its own query, so a big batch at long context is still memory-bound and the throughput gain stops arriving. And the ridge point has been rising with each GPU generation - 153 on an A100, 295 on an H100 - so upgrading hardware makes more of your kernels memory-bound, not fewer.
Autovacuum Tuning and the Cost Budget Every Worker Shares
That autovacuum_max_workers is a throughput setting, so a table that autovacuum cannot keep up with needs more workers. The cost limit is divided among the running workers: three workers each move at a third of the speed of one, the total I/O per second is unchanged, and on a large table adding workers makes each individual vacuum take proportionally longer and the table's peak bloat worse.
Certificate Pinning Runs After Validation, or Not at All
That a pin is a certificate the client trusts, so pinning replaces certificate validation and makes interception impossible. Both halves are wrong. Pinning is an additional intersection test against the chain the platform already built and accepted: OkHttp's CertificatePinner.check() runs on the cleaned chain and returns immediately, doing nothing, if no configured pattern matches the hostname; Chromium ships enable_pkp_bypass_for_local_trust_anchors_ = true, so a pin violation on a chain that ends at a locally-installed root returns PKPStatus::BYPASSED rather than VIOLATED; and Android's <pin-set expiration="..."> stops enforcing pins on the date it names, silently. The other half of the misconception is what is hashed: RFC 7469 §2.4 pins the DER-encoded SubjectPublicKeyInfo, not the certificate, explicitly "to enable operators to generate new certificates containing old public keys" — so the renewal that breaks a pinned client is the one where the key changed, and a certificate fingerprint pasted in as a pin matches nothing on the first connection.
cgroup v2: The Limit That Kills You Is Four Levels Above Your Container
That migrating a node to cgroup v2 renames files and changes nothing — memory.limit_in_bytes becomes memory.max, cpu.shares becomes cpu.weight, same behaviour. Two structural changes bite. First, the single hierarchy means your container's memory limit is only the innermost of three or four limits it is charged against, and when the failing one is kubepods.slice — which the kubelet limits by default — the OOM domain becomes every pod on the node, the badness denominator becomes node allocatable rather than your limit, and oom_score_adj stops cancelling out and starts outweighing resident memory by three orders of magnitude, so the pod that dies is the Burstable pod with the smallest memory request rather than the pod that allocated. Second, since Kubernetes 1.28 the kubelet sets memory.oom.group=1 on container cgroups, so the kernel kills every process in the victim's container instead of the single fattest one.
Chunk Boundaries and the Size Trade
That chunk size is a tuning parameter with an optimum you can search for, and that overlap is the safety margin that makes the search unnecessary. Neither survives contact with the mechanism. An answer cut in half is not half retrieved: the half holding the fact loses the words that made it findable, because the noun the answer refers to is in the other half, and the half holding the noun contains no answer. Overlap only rescues answers shorter than the overlap, and it pays for that by putting near-duplicate chunks into the same top_k, so the same three sentences occupy three of your five slots. Worse, overlap is frequently not applied at all: LangChain's splitters only apply it while merging pieces, so a document whose paragraphs already fit inside chunk_size gets zero overlap however high you set the number.
chunk_size Is Measured in the Wrong Units
That chunk_size controls how much text ends up in a chunk's vector. It controls how much text ends up in the chunk; whether the encoder reads all of it is a separate limit measured in a different unit. all-MiniLM-L6-v2 stops at 256 word pieces — 254 once [CLS] and [SEP] are counted — and its model card describes this in one sentence with no warning, no exception and no truncated flag. The lost text is still in your vector store, still returned verbatim once the chunk is retrieved, so it reads correctly in every debugging session; it simply had no influence on the vector that decides whether the chunk is ever retrieved. And the token-aware fix fails: setting chunk_size to 256 in LlamaIndex's cl100k tokens produces chunks of 278, 292 and 313 word pieces on three real documents, all of them over the 254 the encoder will read.
Chunked Prefill
That prefill only delays the request doing it, and that the token budget is a throughput knob to be turned up. Both are wrong. A forward pass is the unit of scheduling, so a 32k-token prefill run as its own pass freezes every concurrent generation for its whole duration - a hundred-fold jump in inter-token latency for users who sent nothing unusual. And the budget is a latency dial pointing in two directions at once: raising it improves time to first token and worsens everyone's inter-token latency, lowering it does the reverse and eventually costs real prefill throughput because the weight set is re-read once per chunk. There is no setting that improves both, only a size where the chunk still fits in the arithmetic a bandwidth-bound decode step was wasting anyway.
Consumer Groups and Partition Assignment
That adding consumers adds throughput, and that the group balances itself. A partition is assigned to exactly one member, so consumer number P+1 receives nothing at all and sits heartbeating forever; and the default RangeAssignor divides each topic separately, so with three topics of four partitions and three consumers the first member gets an extra partition from every topic and ends up with twice the work of the other two. Neither shows up as an error — the group is healthy, the extra consumers are members in good standing, and the only symptom is lag on partitions nobody is helping with.
Continuous Batching Is Not a Bigger Batch
That continuous batching is a batching optimisation which makes the batch bigger, so it always raises throughput and the lever is the batch-size setting. It is a scheduling-granularity change, not a batching change: the unit of scheduling moves from the request to the single forward pass. All of its gain comes from removing slots that idle while the longest sequence in a batch finishes, so it is worth several times the throughput when output lengths vary and worth almost nothing when they do not. And the batch it forms is capped by how much KV cache is free, never by max_num_seqs. Two engines resolve that cap differently and the difference is invisible in the config: Orca reserves each request's declared max_tokens up front, so it never preempts but wastes most of the memory it reserves, while vLLM allocates on demand and must preempt when it runs short, discarding finished prefill and recomputing it. Turning max_num_seqs up on the second one buys preemption thrashing, not throughput.
Cosine Similarity Is Not Relevance
That the top result by cosine similarity is the chunk most likely to contain the answer, and that a similarity score is a calibrated confidence you can threshold. Cosine measures paraphrase-style likeness in an anisotropic space with no absolute scale, and mean pooling gives the answering sentence a weight of exactly 1/n in its own chunk's vector. Teams raise top_k, tune a threshold, and swap encoders while the actual failure — the answer's chunk ranking sixth because nine sentences of boilerplate were averaged in with it — goes unmeasured, because retrieval recall was never logged.
CPU Requests, Limits and CFS Throttling
That a CPU limit is a ceiling that caps speed, so setting one is harmless hygiene. It is a per-100ms budget: a multi-threaded process can burn the whole budget in a few milliseconds and then sit completely stopped for the remaining 80-90 ms, producing tail-latency spikes on a service averaging a third of its limit. Teams then read the throttling metric as a capacity signal and buy bigger nodes, which makes it worse.
Cross-Encoder Reranking
That a reranker is a stronger retriever bolted onto the end of the pipeline, so adding one fixes bad retrieval. A reranker retrieves nothing. It scores query-document pairs one model call at a time, which is why ColBERT measured BERT-base at 10,700 ms to rerank 1,000 passages on a single V100 — 10.7 ms per pair, or about 26 hours to score MS MARCO's 8.8M passages for one query. It therefore only ever sees the candidate window the first stage returned, and if the answer is at rank 340 with a window of 50, no reranker in existence can recover it. Recall is fixed before the reranker starts; the reranker only decides precision inside a set whose ceiling was set by a model that never saw your query and the document at the same time.
Databricks Liquid Clustering
That CLUSTER BY is PARTITIONED BY without the directories, and that OPTIMIZE on a clustered table is OPTIMIZE ZORDER under a new name. The incremental part is a candidate-selection rule, not a better sort: OPTIMIZE ZORDER makes every file in a partition a candidate on every run, while clustering excludes files already sealed into a full-size ZCube. The same rule is why changing clustering keys silently stops improving your layout until you run OPTIMIZE FULL, and why very small OPTIMIZE batches rewrite the same bytes several times over.
Deadlocks: Nothing Is Watching Until Your Own Timer Fires
That a deadlock detector is watching the lock table, so cycles are caught as they form, and that deadlock_timeout is how long the server tolerates one before breaking it. There is no watcher. The check is optimistic and self-service: it runs once per lock wait, deadlock_timeout after that wait began, and never again for that wait. Raising the setting does not prevent a single deadlock — in a contended workload it leaves the whole queue behind the cycle stuck for exactly that much longer, and it blinds log_lock_waits at the same time, because both use the same timer.
Deletion Vectors and Merge-on-Read
That deletion vectors make deletes cheap. They make deletes cheap to write and hand the bill to every subsequent read. The data file keeps its original bytes on disk and in the scan, and because the file's statistics become wide bounds rather than tight ones, a file whose rows are entirely deleted still advertises the min/max it had before and is still opened by a query that its live rows can no longer satisfy.
Delta Lake Optimistic Concurrency
That ConcurrentAppendException means two writers hit the same rows, and that partitioning or raising the isolation level fixes it. Conflict detection ignores data predicates entirely; on an unpartitioned table any concurrent append conflicts with any transaction that read the table, Serializable makes it strictly worse by re-admitting blind appends, and partitioning permanently disables the row-level concurrency that would have resolved it.
Delta Small Files and Bin-Packing OPTIMIZE
That the small-file problem is a scan-throughput problem, fixed by running OPTIMIZE more often or raising the target file size. Both levers frequently do nothing. OPTIMIZE never merges across a partition boundary and drops any bin holding one file, so a table partitioned finely enough that each directory receives one or two files per batch is uncompactable by construction. The cost being paid is mostly not throughput either: it is per-file task overhead in the query planner and one checkpoint row per live file on every table open.
Dense Vector Retrieval
That retrieval quality is a property of the embedding model, so a better model fixes it. The parameters that decide what comes back are chunk size and what pooling does to rare exact tokens — a short restatement of the question outranks the long passage that answers it, and an identifier like IL-4021 carries all the information and almost none of the vector.
Dynamic File Pruning
That a selective join produces a selective scan: if the dimension filter matches four thousand rows out of two hundred thousand, dynamic file pruning will read roughly four thousand rows' worth of files. What is pushed down is a set of key values, and a file survives if any one of them falls between that file's recorded minimum and maximum for the join key. Four thousand values scattered evenly across the key domain therefore keep every file alive on a perfectly Z-ordered table, while the same four thousand values in one contiguous block keep five. The two failures that follow are both silent: when the join key sits past delta.dataSkippingNumIndexedCols there is no min/max to test and nothing can be excluded, and when the build side outgrows spark.sql.autoBroadcastJoinThreshold Spark replaces the pruning subquery with a literal true. In both cases the physical plan still shows a dynamicpruning expression on the scan and the query profile still reports the feature as applied.
Entity Resolution in a Knowledge Graph
That the pipeline deduplicates entities, because the step after the merge summarises a list of descriptions into one. It does not compare anything: membership was already decided by exact string equality. The fragments split an entity's edges, which breaks multi-hop paths and pushes whole subgraphs outside the largest connected component, where cluster_graph discards them and no community report ever mentions them.
Excessive Agency: Tool Surface Versus Credential Scope
That narrowing the tool narrows the risk: name it read_emails, document it as read-only, validate its arguments, and the agent cannot send. The tool is a client; the authorisation lives in the mailbox. OWASP separates three independent causes — excessive functionality, excessive permissions, excessive autonomy — and teams almost always attack the first, which is the cheapest to fix and the least load-bearing. Removing a tool from the manifest removes nothing from the token, and the credential is what an attacker inherits.
FlashAttention
That FlashAttention is a faster approximation of attention, in the same family as Linformer or Performer, so it trades a little accuracy for speed. It computes exactly the function standard attention computes, and it does so while performing slightly more arithmetic, not less. The speedup comes entirely from bytes not moved between HBM and the chip. The second half of the misconception is that it shrinks the KV cache: it does not touch the cache, only the N x N intermediate, so it buys long prompts and nothing at all in the memory ledger of decoding.
Getting the Disk Back: VACUUM FULL, pg_repack and What They Really Lock
That VACUUM FULL costs you exactly as long as the rewrite takes, so a quiet window makes it safe, and that pg_repack is the lock-free version. Both halves are wrong. The ACCESS EXCLUSIVE request queues behind whatever query is already running, and because a request that conflicts with a waiting request must also wait, every query arriving after it queues too — so the outage starts before the rewrite does and lasts the running query plus the rewrite. pg_repack still needs ACCESS EXCLUSIVE twice, resolves the wait by cancelling and then terminating your backends, and needs twice the size of the table in free disk, which is the one thing you do not have.
GraphRAG Community Detection
That a community is a topic and that max_cluster_size is the knob for how fine-grained your topics are. A community is whatever maximises modularity on the extracted edge list — the clustering never reads your text — and max_cluster_size does not change the level-0 partition at all; it only decides which already-formed communities get split into a deeper level. The parameter that really decides how many communities exist, Leiden's resolution, is hard-coded to 1.0 in the source and is not a configuration key.
GraphRAG Global Search Fan-Out
That global search retrieves the communities relevant to your query. It performs no retrieval at all: the query is not consulted when the batches are formed, so a question about one entity costs exactly as much as a question about the whole corpus, and the reduce step then discards most of the map output it just paid for.
GraphRAG Indexing Cost
That indexing is roughly one model call per chunk, so the bill scales with how much text you have. It is closer to fifteen calls per document, and the three largest multipliers are not corpus size at all: max_gleanings defaults to 1 and therefore doubles the extraction stage, every gleaning re-sends the entire conversation including the chunk, and reports are written for every community at every level of the hierarchy rather than for the level you intend to query.
Grouped-Query Attention
That GQA is a compute optimisation — fewer heads, less math, a smaller and slightly dumber model. Every one of those is wrong. Query heads are untouched, the attention FLOPs of a decode step are identical at 32 kv heads and at 1 because the shared keys are broadcast to every query head rather than skipped, and the parameter saving is about 1% of the model. The entire win is bytes of KV cache per token, which is why it shows up as concurrent sequences and not as a faster single stream. The second half of the misconception is that fewer kv heads is monotonically better: below the tensor-parallel degree the serving engine replicates the kv heads across ranks, so aggregate cache stops falling entirely, and the quality cost of the last step from 8 heads to 1 is the one step that actually hurt in the paper.
Heap-Only Tuple Updates and fillfactor
That an UPDATE only writes to the indexes whose columns it changed, and that Postgres decides this per index. It is one all-or-nothing test per statement: change a single column that any non-summarizing index references and every index on the table gets a new entry, including the six that index columns you did not touch. And even an update that touches no indexed column falls back to that same cold path whenever the old row's page has no free space — which at the default fillfactor of 100 is most pages, most of the time.
How kube-scheduler Places a Pod
That a pod goes Pending because the cluster is out of capacity, so the fix is a bigger or extra node. The scheduler never reads utilisation: it compares the pod's requests against allocatable minus the sum of every already-placed pod's requests, so a node running at 12% CPU can be 100% requested and refuse everything. Worse, because placement is greedy and per-pod with no backtracking, the default LeastAllocated scoring spreads small pods evenly and leaves every node with a hole too small for the next big one — the cluster has the CPU free, just never in one place.
HSTS Protects Every Visit Except the First
That adding the Strict-Transport-Security header makes a site HTTPS-only. The header is an instruction to a browser that has already completed an error-free HTTPS conversation with you, so it does nothing on a first visit, nothing after a cleared profile, and nothing at all for a client on a network where the attacker strips it — RFC 6797 calls this the bootstrap MITM vulnerability in section 14.6. The other half is worse in the opposite direction: once stored, the policy is enforced by the browser with no click-through on any certificate error, and it can only be revoked by serving max-age=0 over the very HTTPS connection that may be the thing that broke. max-age is not a setting, it is the length of an outage you are agreeing to in advance.
Hybrid Retrieval and Reciprocal Rank Fusion
That hybrid search means blending a BM25 score with a cosine score, that RRF is a weighted average of the two, and that a reranker is a small quality tweak at the end. BM25 is unbounded and corpus-dependent while cosine is bounded and anisotropic, so any weighted sum is silently dominated by whichever column has the larger numbers on that query. RRF never sees either number: it fuses positions, which is why a document that is rank 1 by a factor of three in one list can lose to a document that is merely second in both. And the reranker teams skip is the only stage that reads the query and the chunk together — but it can only reorder what the candidate window already returned.
Index-Only Scans and the Visibility Map
That an index-only scan does not read the table, so a covering index makes the heap irrelevant. It reads the heap for every row whose page is not marked all-visible in the visibility map, and only vacuum sets that bit while any write clears it — so on a table taking continuous writes an index-only scan does as many heap accesses as a plain index scan, in random order, and the planner picked it precisely because pg_class.relallvisible said it would not have to.
Indirect Prompt Injection
That the system prompt is a privileged channel and retrieved content is inert data the model merely reads. There is no privilege bit anywhere in the context window: attention runs over one concatenated sequence, and 'instruction' is a statistical property of the text, not of its provenance. Teams therefore harden the chat box — the one input a human types into — ship an agent that reads issues, emails, PDFs and web pages, and discover the attacker never needed the chat box. OWASP states plainly that RAG and fine-tuning 'do not fully mitigate prompt injection vulnerabilities'.
Isolation Levels: What Each One Still Lets Through
That the levels are a ladder of how much locking you get, so moving from READ COMMITTED to REPEATABLE READ makes concurrent updates safe. Postgres's REPEATABLE READ is snapshot isolation: one frozen snapshot, and write conflicts become errors instead of corruption — but it still permits write skew, where two transactions each check a rule, each write a different row, both commit, and the rule is now broken. And the protection is not a property of your session alone: SERIALIZABLE only detects cycles among other SERIALIZABLE transactions, so one READ COMMITTED writer voids the guarantee.
JWT Validation Is Not Signature Verification
That a JWT with a valid signature is a valid token. The signature establishes only that some key you hold signed these bytes. It says nothing about which issuer minted the token, which service it was minted for, whether it is still in date, or whether the algorithm and key were chosen by you or by the token — and a library called with defaults checks none of those.
Kafka 4 Did Not Move Your Group to KIP-848
That upgrading the cluster to Kafka 4.x switches consumer groups onto the new protocol, so the stop-the-world rebalance pause goes away by itself. It does not. Kafka 4.0 changed the *broker* default — group.coordinator.rebalance.protocols went from [classic] to [classic, consumer] — but the *client* config group.protocol still defaults to "classic" in every released version through 4.3.1 and on trunk, so a group stays on JoinGroup/SyncGroup until each application opts in. The second half of the misconception belongs to people who do opt in and expect the pause to shrink uniformly: KIP-848 removes the group-wide barrier entirely rather than shortening it, so a slow member now delays only the partitions it personally has to hand over — and if it does hold one, it is fenced after rebalance.timeout.ms (its max.poll.interval.ms) with "failed to transition from epoch N", which is worse for that partition, not better.
Kafka Consumer Lag
That lag is a health metric whose good value is near zero. It is a position, and a position tells you nothing on its own. A lag of two million that is falling by 8,000 records a second clears in four minutes; a lag of 400 that is not falling never clears at all, and the alert threshold everyone writes fires on the first and ignores the second. Two further beliefs come apart under the same pressure. That zero lag means you are current — it can equally mean the producer died, or that auto.offset.reset moved you to the end of the log and you skipped a day of data. And that non-zero lag means you are behind — a transactional producer leaves a commit marker that occupies an offset no consumer will ever return, so a fully caught-up group can sit at exactly 1 per partition forever.
Kafka Consumer Rebalancing
That a rebalance is a brief hiccup the client library absorbs. Under the assignor Kafka still selects by default it stops every consumer in the group; a consumer whose batch outruns max.poll.interval.ms removes itself with a LeaveGroup and starts a self-inflicted rebalance storm; and raising max.poll.interval.ms to stop the storm widens the group's worst-case stall by exactly the same amount, because the group's rebalance timeout is the maximum of its members' poll intervals.
Kafka Partitions
That the partition count is a throughput dial you can turn up when you need more consumers and back down when you do not. It is neither reversible nor free. Kafka refuses to reduce it — the controller answers "would not be an increase" — so every expansion is permanent. And because the producer picks a partition with murmur2(key) & 0x7fffffff % numPartitions, changing the divisor remaps most keys: a key's old records stay in the partition they were written to while its new records go somewhere else, and the two are consumed independently. The per-key ordering guarantee people rely on is not weakened by adding a partition, it is broken for every key that moved.
Kernel Enforcement Cannot See Intent
That putting Tetragon or Falco under an agent contains it, because eBPF sees everything and blocks in-kernel at microsecond latency. Coverage really is that good and the block really does hold. The gap is semantic: the hook sees an outbound connection to an allowed address, not that a prompt injection caused it or that the bytes are rows from a table the agent was never meant to query. Because a legitimate agent's paths, hosts and processes drift prompt to prompt, a learned allowlist is either loose enough to contain the attacker's primitives too or tight enough to break the agent — and the settings in between shrink to nothing as that drift grows. The designs that work concede this by construction: they use eBPF to see and to redirect, and put the decision at a layer that has the nouns — an L7 proxy, a per-agent identity, a network policy, an admission rule. The cost of not knowing that is a control that is trusted, correct, and produces no security.
Key Rotation Is Two Overlaps, Not One Switch
That rotating a signing key is a moment: generate a key, start signing with it, delete the old one. It is two overlaps of different lengths, and each has its own failure. The new key must sit in the published key set for at least as long as your slowest verifier caches that document before you sign anything with it. The old key must stay published for at least as long as the longest-lived token you signed with it, because a token already issued cannot be re-signed. Refetching on an unfamiliar kid — which the OpenID Connect specification tells verifiers to do — closes the first gap and does nothing whatever for the second.
Late Interaction and MaxSim
That late interaction is a cheap cross-encoder — that the model somehow reads the query and the document together and just does it faster. It does not. ColBERT's document encoder runs offline, alone, exactly like the bi-encoder that filled your vector index; the ColBERT paper's own words are that it 'independently encodes the query and the document'. The only thing deferred is the pooling. And the operator that replaces pooling, MaxSim — sum over query embeddings of the maximum cosine against any document embedding — contains no document-length term at all. Adding text to a document takes the maximum over a superset, so it can raise the score and can never lower it. The 'see also' footer at the bottom of your docs page is a ranking signal under ColBERT and a penalty under a mean-pooled embedding, and nobody who switches retrievers is told this.
Lax by Default Is One Browser's Policy, Not the Web's
That leaving SameSite off is safe because browsers now default to Lax. Chrome does. Firefox ships network.cookie.sameSite.laxByDefault=false and Safari never implemented the default at all, so on those browsers an unlabelled session cookie is attached to a cross-site top-level POST exactly as it was before SameSite existed. Even in Chrome the default is the weaker Lax-allowing-unsafe mode, which sends an unlabelled cookie on a cross-site POST for the first 120 seconds of the cookie's life — and Lax of either kind always sends the cookie on a cross-site top-level GET.
Linux does not implement RFC 896, and TCP_NODELAY is not what fixed your latency
That Nagle's algorithm delays any small write while data is unacknowledged, that the resulting 40 ms is a flat tax on request-response traffic, and that TCP_NODELAY is the fix. Linux does not implement RFC 896: tcp_nagle_check applies Minshall's variant and blocks a partial segment only when the last sub-MSS segment sent is still unacknowledged, so a write of exactly two full segments followed by a small write never stalls, while a 4-byte header followed by anything always does. The 40 ms is not paid on the opening exchange either, because Linux quickacks the first rcv_wnd/(2*rcv_mss) segments up to a cap of 16 and only begins delaying once one reply-within-ato has pushed the socket into pingpong mode, which net.ipv4.tcp_pingpong_thresh sets at 1. And TCP_NODELAY removes only the sender's half of the interaction: the receiver still delays its acknowledgement by TCP_DELACK_MIN, which is a hard 40 ms floor that does not shrink with the round-trip time, so on a 0.2 ms path the delay is 200 round trips. The write pattern is the defect; one writev fixes both halves and puts fewer packets on the wire than TCP_NODELAY does.
MCP Tool Poisoning and Rug Pulls
That approving an MCP server is a decision about what its tools do, checked once at install time. What was approved is a name and a launch command; the descriptions arrive later, can differ per session, can change after approval with no re-prompt, and are usually truncated or hidden in the client UI so the human never sees the text the model reads. Worse, the descriptions are not scoped to their own server: one server's description can rewrite how the model uses a different, trusted server's tool, so the blast radius of a poisoned server is every server connected to the same context.
Memory Limits, OOMKill and Exit Code 137
That a memory limit behaves like a CPU limit — a ceiling the kernel enforces by slowing you down, or at worst an allocation failure the runtime can catch. Memory is not compressible, so there is nothing to throttle: the process is killed outright, with no stack trace and no chance to handle it. Two further beliefs follow from it and are just as wrong. That the pod moves to a bigger node — it does not; the container restarts in place, forever, as CrashLoopBackOff. And that the memory *request* buys you protection — it is written to no kernel file at all, and only changes an oom_score_adj number and where the scheduler puts you.
More Hops Is Not More Answer
That hop depth is a recall knob: if the answer was not found at one hop, two or three hops will find it. Reachability is not retrieval. The neighbourhood grows multiplicatively with depth, the context window does not grow at all, and the rows that survive packing are chosen by degree — so the specific low-degree edge that carries the answer ranks last in a pool of thousands, while the corpus's biggest hubs fill the prompt. Past depth two GraphRAG's local context contains no relationship rows at all, because the entity table is packed first and consumes the whole budget.
mTLS Tells You Which CA Signed the Caller, Not Which Caller It Is
That switching on mutual TLS authenticates the calling service. It authenticates the issuer. RFC 8446 §4.4.2.4 states that detailed certificate validation is out of scope for TLS, and there is no client-side equivalent of the server-name check RFC 9525 defines — nothing in the handshake compares the client certificate against an expected identity. With nginx's ssl_verify_client on and one internal CA in ssl_client_certificate, every workload in the fleet presents a certificate that verifies, so any of them can call any route as any other. Widen the trust file from the issuing CA to the root, or paste in /etc/ssl/certs/ca-certificates.crt, and the set of peers that pass the handshake grows without a line of application code changing. The check most teams then write — $ssl_client_verify == "SUCCESS" — is true of every one of them and therefore rejects nobody.
MVCC, Dead Tuples and What VACUUM Does Not Do
That VACUUM reclaims disk space and that running it more often fixes bloat. Plain VACUUM never shrinks the file except by truncating a wholly empty tail, and a single old transaction, replication slot or prepared transaction pins the removable cutoff so that no dead tuple newer than it can be removed at any frequency — the table bloats while every dashboard shows autovacuum succeeding.
num_heads Is Not a Capacity Knob
That the number of heads is a size setting: more heads means more parameters, more arithmetic, and a more expressive layer, so raising num_attention_heads is a way to make the model stronger. Nothing about the cost changes. With d_k = d_v = d_model/h the four projection matrices together are 4 x d_model^2 weights at every head count, and the score and value matmuls do 2 x n x d_model multiply-accumulates per token at every head count. The one thing that does change is head_dim, and head_dim is a hard ceiling on the rank of that head's n-by-n score matrix — so heads trade the complexity of a single pattern for the number of patterns the layer can run at once.
Offset Commits, and the Window That Decides Your Semantics
That enable.auto.commit is the unsafe setting and switching to a manual commitSync() after each batch gives you correctness. Both are at-least-once and both duplicate on a crash; manual commit only moves the window from auto.commit.interval.ms to one batch, and with max.poll.records at its default of 500 the manual window is routinely the larger of the two. The genuinely different behaviour is loss, not duplication: the javadoc says records are 'considered consumed after they were returned to the user in poll', so the instant processing stops being synchronous with the poll loop — a thread pool, an async handler, a buffered writer — auto-commit starts committing records nobody has processed, and a crash silently skips them forever. Exactly-once is not a commit setting at all; it needs the transactional producer writing the offsets into the same transaction as the output.
PagedAttention
That PagedAttention shrinks the KV cache, or approximates attention, or is a flag you switch on. It does none of those: bytes per token are unchanged, the attention output is numerically exact, and in vLLM it is the only allocator there is. What it removes is allocator waste — space reserved for a request's declared max_tokens that the request never generates, plus rounding and holes from placing variable-sized contiguous chunks. That waste is why existing systems held as little as 20.4% real tokens in their KV memory. The consequence people miss is that the size of the win is set entirely by how far a request's declared maximum overshoots its actual output: with exact output lengths known in advance, paging recovers almost nothing and still pays a 20-26% slower attention kernel. And paging does not make memory infinite — it converts a hard admission limit into on-demand allocation that can fail mid-generation, which is what preemption and recompute are.
PKCE and state Defend Different Things
That PKCE superseded state, so a client using PKCE can drop it. PKCE does provide CSRF protection, but only for codes the authorization server actually bound to a challenge. A server that treats the presence of code_challenge as the switch that enables PKCE will happily issue a code with no binding, ignore the code_verifier that arrives with it, and hand the tokens over — which is precisely the case state would have caught.
Prefix Caching Reuses a Prefix, Not Your System Prompt
That the cache keys on the text you think of as shared, so a fixed system prompt is 'the cached part' and every request carrying it skips that work. The key is a chain: block k's hash covers blocks 0 through k, so one differing token at position p makes every block after p miss even where the tokens are byte-identical. Move an 11-token timestamp from the end of the template to the front and the hit rate goes from 92.8% to 0.0% with no other change. Two further consequences. Matching is floored to whole blocks, so a 24-token shared prefix reuses 16 tokens at the default block size and 0 tokens at --block-size 64 — a short shared prefix can be worth literally nothing. And the logged hit rate is token-weighted over the last 1,000 requests, not a fraction of requests served, so a measured 66.1% can come with a time-to-first-token that has not moved at all (6.2 ms cached against 6.3 ms cold).
Prompt-Level Versus Process-Level Isolation
That 'the agent is sandboxed' is one fact. It is four different facts about four enforcement points, and the useful question is which set of actions each point sits astride. A regex over proposed shell commands is bypassed by the shell's own grammar; a container blocks the process and not the Markdown image the chat client fetches; a domain allowlist that includes any host the attacker can read — a paste site, a package registry, your own telemetry endpoint, DNS — is an open channel measured in bits per request, not a wall. Teams pick a layer, feel done, and never enumerate the primitives that go around it.
QoS Classes: Guaranteed, Burstable, BestEffort
That QoS is a setting, and that Guaranteed is a promise the kubelet keeps. Neither is true. You cannot set qosClass — it is derived by ComputePodQOS from the numbers you already wrote, so a sidecar injected without resources silently downgrades a carefully-Guaranteed pod to Burstable. And the kubelet's eviction ranking never looks at the class at all: rankMemoryPressure sorts on whether usage exceeds requests, then Pod Priority, then usage above requests. The familiar ordering BestEffort, Burstable, Guaranteed is a consequence of those three comparisons, not a rule, and it breaks whenever Priority disagrees — a Guaranteed pod at priority 0 is evicted before a Burstable pod at priority 1000.
Query Rewriting and HyDE
That HyDE and query rewriting are the same family of trick — clean up the question, get better results — and that a hallucinated hypothetical document is a defect the technique tolerates. The generated document being wrong is not incidental; the paper says it 'can and is likely to be ungrounded factually' and relies on the encoder's 'dense bottleneck' to strip the invented detail. That works when the errors are random, because averaging N generations cancels them. It does nothing when the model is systematically wrong — when it believes your default timeout is 30 seconds and your docs say 5 — because every generation is wrong in the same direction and the mean of eight identical errors is the error. And the entire benefit is proportional to the question-to-answer gap in your encoder: HyDE's own authors call using it with a fine-tuned retriever 'not the intended usage' and measure smaller instruction models making that retriever worse.
Raising max_position_embeddings Does Not Extend Context
That a model's context length is the value of max_position_embeddings, so raising it extends the window. RoPE has no per-position parameters to run out of; the limit is that roughly a quarter to a half of the dimension pairs never complete a single full rotation inside the training window, so at any longer position they are rotated to angles the model has never been asked to interpret. For Llama 2 7B that is 18 of the 64 pairs. The scaling methods are not conveniences — position interpolation removes every unseen angle but shrinks the separation between adjacent positions to 0.1% of what it was at a scale factor of 32, and YaRN exists because those two failures live in different halves of the frequency ladder.
Recall@k, MRR and nDCG
That a retrieval metric measures retrieval quality, so a pipeline change that raises nDCG@10 has made the product better. Every one of these metrics divides by the label set: trec_eval computes recall as rel_so_far / num_rel where num_rel is the number of judged-relevant documents, so a relevant document nobody labelled is scored as a mistake, and a query with no judged document is silently dropped from the average. 94% of MS MARCO's development queries have exactly one labelled passage, which makes recall@k a hit rate and MRR the only metric with anything to say; when Arabzadeh and colleagues put a modern ranker's top result next to that one label, crowd workers preferred the unlabelled result 59% of the time. And because near-duplicates of a relevant chunk are themselves relevant, a retriever can raise recall@k and nDCG@k by returning the same fact five times, while the generator loses the second fact it needed to answer at all.
Replication Slots: WAL Kept for a Consumer That Left
That a slot only matters while its consumer is connected, so a decommissioned standby or a stopped change-data-capture job is harmless. Holding WAL for an absent consumer is exactly what a slot is for: restart_lsn freezes, every checkpoint removes nothing, and pg_wal grows at the full WAL rate until the disk fills and the server PANICs. Separately, the slot's xmin or catalog_xmin holds the vacuum horizon still cluster-wide, so the disk fills from both ends at once.
Retrying a 40001: Everything the Second Attempt Must Forget
That handling a serialization failure means catching the error and re-running the failed statement, and that once you have a retry loop the transaction is safe. Neither half holds. The statement did not fail, the transaction did — the connection is in a failed transaction block and will answer 25P02 to everything until you roll back. And a retry that carries a value read during the failed attempt into the new one reproduces exactly the anomaly the abort prevented, silently, with no error at any point: the model in this lesson loses 148 increments that way while reporting a perfect success rate. Meanwhile the loop itself is not free — on 2 contended rows, doubling from 8 clients to 16 buys 6% more completed work (342 to 363) while attempts per success go from 3.93 to 7.23; drop the backoff as well and the same 16 clients burn 106.9 seconds of server time inside an 8-second window and abandon 600 operations.
Rotating the Session ID Protects the Login, Not the Session
That calling session_regenerate_id() — or cycle_key(), or reset_session() — at login is what fixes session fixation. It removes exactly the attacks whose whole method is planting an identifier before the victim signs in. It does nothing about the old record, which PHP keeps by default because delete_old_session defaults to false and deleting it immediately breaks concurrent requests. It does nothing about privilege changes that are not a login, such as a second-factor step-up. It does nothing about a password change, because with no server-side registry and no password-bound session the change writes one row in the users table and ends no session at all. And it does nothing on any code path that does not run the sign-in handler, such as a remember-me cookie restoring a session onto whatever identifier the browser presented — which the server will happily adopt, because session.use_strict_mode has defaulted to 0 since the day it was added.
Scaled Dot-Product Attention
That attention is O(n²) full stop, so each generated token costs quadratically more as context grows, and that the quadratic term is what makes long context expensive. Both halves are wrong. The n² comes from running n queries against n keys in a single pass, which only happens during prefill; a decode step has exactly one query, so it does n dot products, not n² — linear per token. And even in prefill the quadratic attention term does not overtake the linear-in-n weight matmuls until roughly 26,000 tokens on an 8B model, so at ordinary prompt lengths attention is a minority of the arithmetic. People also read the causal mask as an optimisation that halves work, when what it actually buys is the guarantee that row i of a parallel prefill is identical to what a sequential decode would have produced at step i.
SELECT FOR UPDATE: Why Eight Workers Do the Work of One
That adding FOR UPDATE to a queue poller makes N workers safe, so N workers do N times the work. They do not: every worker's scan reaches the same first eligible row, N-1 of them block on it, and throughput collapses to one transaction per hold time no matter how many workers you add — FOR UPDATE SKIP LOCKED is not a speed-up of that plan, it is a different plan that returns different rows. The second half of the belief is that the lock covers the condition you selected on. It covers tuples. Nothing stops a concurrent INSERT of a row that would have matched, and a FOR UPDATE lock on a parent row blocks INSERTs into any child table that references it, because a foreign-key check runs SELECT ... FOR KEY SHARE and FOR UPDATE is the one mode that conflicts with it.
Slow start is not slow, and your keep-alive connection is not warm
That slow start is a slow warm-up phase you can wait out, that it ends early in any real transfer, and that a long-lived keep-alive connection stays warm. Growth is exponential, so slow start is the fastest thing TCP does; but its cost is counted in round trips rather than in seconds, which means a 1 MB response costs the same number of round trips on a 10 Mbps link and a 10 Gbps one, and for anything under a few megabytes slow start is not a phase of the transfer, it is the whole transfer. Linux then leaves slow start well below the bandwidth-delay product because CUBIC's HyStart exits on a delay rise once cwnd reaches 16, and net.ipv4.tcp_slow_start_after_idle defaults to 1, which halves the window once per retransmission timeout of idleness down to the initial 10 segments — so a connection used once a second is cold on every request.
Spark Broadcast Hash Join
That broadcast() is a free speedup for any small-looking table and that raising spark.sql.autoBroadcastJoinThreshold makes more joins fast. The planner tests a compressed on-disk estimate, the driver pays the decompressed in-memory price, and every executor holds a full copy for the life of the query — so the setting that looks like a speed dial is really a driver-heap and cluster-memory dial.
Spark Executor Memory
That an executor out of memory, or spilling, means the executor is too small, so raising spark.executor.memory fixes it. Raising memory raises every task's ceiling equally, so it stops the skewed task spilling without making it any less skewed — the stage is still gated by the one task holding 40x the rows, and the only visible change is that the spill metric disappears.
Spark Partitioning
That repartition(n) controls how work is distributed for the rest of the query, so raising n rebalances a skewed job. Round-robin repartitioning is discarded by the very next shuffle, which re-hashes rows by the operator's own key, and a key that maps to one partition id cannot be divided by any value of n.
Spark Shuffle
That a slow shuffle is a network or partition-count problem, so raising spark.sql.shuffle.partitions or calling repartition() will fix it. Neither divides a single hot key, which is what is actually gating the stage.
Spark Table Statistics
That Spark knows how big your data is, so a table small enough to broadcast will be broadcast. Spark plans with an estimate that is the compressed on-disk size, is unchanged by any WHERE clause by default, and is the product of both sides above a join — so it is routinely wrong by 100x in both directions, and the join strategy follows the estimate rather than the data.
Speculative Decoding Spends Arithmetic You May Not Have
That speculative decoding is a free 2-3x that you tune by raising the acceptance rate, so a better draft model always means a bigger speedup. It is neither free nor mainly about acceptance. It performs strictly more arithmetic than plain decoding — Leviathan et al. put the increase at (1-alpha)(gamma*c_hat + gamma + 1)/(1 - alpha^(gamma+1)) — and pays for it out of the tensor cores that a bandwidth-bound decode pass leaves idle. The paper's walltime analysis says so in as many words: it assumes 'we have enough compute resources to support the increased concurrency', and its measurements were taken at batch size 1. On a server that has already spent that idle arithmetic on a large continuous batch, the identical setting becomes a throughput regression, which is why the same feature is reported as a 2.8x win and as 'slower than baseline at concurrency > 8'. And a better draft model can lower the speedup rather than raise it: in the paper's own table a T5-large draft with alpha=0.82 yields 1.7x where a T5-small draft with alpha=0.75 yields 3.4x, because the cost coefficient grew faster than acceptance did. The one thing that genuinely does not change is the output distribution.
Static Membership Trades a Short Group Pause for a Long Local Outage
That group.instance.id removes rebalances, so a deploy stops costing anything. What it removes is precisely one rebalance pair — the LeaveGroup on close and the JoinGroup on return — and it removes it by making the coordinator wait instead. The partitions of a restarting static consumer are not reassigned to anybody; they are simply not consumed until it comes back, so a rolling restart of six consumers with a 40-second restart moves more partition-seconds of consumption than the twelve eager rebalances it replaced. Worse, the parameter you must raise to cover a slow deploy — session.timeout.ms — is the same parameter that governs how long a crashed consumer's partitions sit unowned, and a scale-down, where the consumer is never coming back, now costs a full session timeout instead of a few seconds because no LeaveGroup was ever sent. Static membership is a latency-versus-detection trade, not a free win, and under group.protocol=consumer you cannot even set session.timeout.ms — the client throws ConfigException and the broker's group.consumer.session.timeout.ms caps at 60 seconds.
TCP Congestion Control
That throughput is set by the link's bandwidth, so a slow transfer means buying more of it. A single flow is bounded by window/RTT, and the window is capped first by the receive window, then by the loss rate a loss-based controller has to operate against — upgrading 1 Gbps to 10 Gbps moves none of those, and oversized buffers along the path make the window grow far past the bandwidth-delay product, inflating latency while throughput stays flat.
Tensor Parallelism Does Not Divide Your KV Cache by N
That --tensor-parallel-size N divides everything by N, so eight GPUs give eight times the weights capacity, eight times the KV cache room and eight times the throughput. Three parts of that are wrong. Grouped-query attention leaves most models with 8 key-value heads, and vLLM computes heads per GPU as max(1, total_num_kv_heads // tensor_parallel_size), so past N = 8 it replicates instead of splitting: on Qwen3-32B at 32k context, going from 8 GPUs to 16 takes concurrent sequences from 60 to 64, a 1.07x return on twice the hardware. Capacity is per-GPU and not summed, because every GPU holds a head-shard of every resident sequence rather than its own set of sequences. And the two all-reduces per layer do not shrink with N — their volume per GPU rises toward twice the tensor — so on a PCIe machine an 8,192-token prefill chunk at N = 32 spends 81% of its time in communication.
The Agent Confused Deputy
That the third-party consent screen is the human checkpoint, so if the user saw it once the flow is authorised. The cookie the authorization server set says 'this user consented to mcp-proxy', and mcp-proxy is the same string for every MCP client that will ever connect. An attacker who dynamically registers a client with redirect_uri=attacker.com gets the consent screen skipped and the authorization code delivered, without the user approving anything. The MCP specification's fix is not more consent screens — it is moving consent to the proxy, keyed per client_id, and refusing to set the state cookie until after that consent.
The Client Secret Is Not What Makes the Code Flow Safe
That the client secret is what makes the authorization code flow secure, so a flow with a correctly authenticated client is safe. The secret proves which application is calling the token endpoint. It proves nothing about where the code came from, which browser session it belongs to, or whether it has already been redeemed. The checks that carry that weight are the exact-match redirect_uri comparison, single-use code semantics, and the PKCE binding — and a public client such as a browser app or a mobile app has no secret at all yet is not thereby insecure.
The Delta Transaction Log
That _delta_log is an audit journal beside the real table, so a Parquet file dropped into the directory becomes queryable and a deleted one disappears. The log is the table: a file with no add action is invisible no matter how much data it holds, and a removed file sits on storage until VACUUM. The second half of the misconception is that checkpoints make reading the log free — they only shorten the tail of JSON commits, while the checkpoint itself carries one row per live file, so a table with millions of small files pays seconds of metadata time before any data is read.
The Free Space Map: Freed Is Not the Same as Available
That once VACUUM reports the dead tuples removed, the space is back in play, so a table that keeps growing must mean vacuum is not running. Freeing space and advertising it are two separate steps. VACUUM records each page's new free space at the bottom of the map immediately, but GetPageWithFreeSpace descends from the root, and the root is refreshed only by FreeSpaceMapVacuumRange — once per index-vacuum cycle and once when the scan ends. On an 8 GB table at default settings that is a single refresh 233 seconds in, and every row inserted before it extends the file. On-access pruning never refreshes the map at all, deliberately.
The Gateway Reports On Its Own Denominator
That transparent interception means the gateway governs the agent's model traffic, because the words 'transparent' and 'no source changes' make coverage sound like a property of eBPF. It is a property of your hook set. A cgroup/connect4 program sees TCP over IPv4 from the processes in its scope, opening new connections — not IPv6, not a subprocess outside the scope, not a connection that was already established, and never a unix socket. Each of those is a live model call that never reaches the proxy. The failure is invisible because the gateway's own dashboard is computed over the calls it handled: a gateway governing 59.5% of the fleet reports 100% compliance, and the missing calls are not counted as violations, they are simply absent. On top of that, reading the request at all requires the payload to be readable, so a hosted model over TLS means terminating your own agents' connections with a certificate you issue; the proxy sits in the data path with a latency and a failure mode; and a gateway that rewrites prompts is your own infrastructure writing into the model's context.
The Group Coordinator Does Not Assign Your Partitions
That the group coordinator is a cluster-wide service which decides who gets which partition. Neither half holds. Which broker coordinates a group is decided by the characters in the group's name — Utils.abs(groupId.hashCode()) % offsets.topic.num.partitions picks a __consumer_offsets partition and the coordinator is that partition's leader — so renaming a group moves it to a different broker and unrelated groups pile up on the same one. And the broker never runs an assignor under the classic protocol: AbstractCoordinator's own javadoc says "the coordinator select the members of the group and chooses one member as the leader. The leader collects the metadata from all the members of the group and assigns state." A skewed assignment, an assignor you cannot roll out in one deploy, and a group that will not settle are therefore client-side faults that present as broker problems.
The HPA Does Nothing Until You Are 10% Past Target
That a HorizontalPodAutoscaler with `averageUtilization: 80` keeps the workload near 80%, so a workload sitting above 80% and not scaling means the metrics pipeline is broken. The controller applies a dead band: `tolerances.isWithin(usageRatio)` returns the current replica count unchanged whenever the ratio of current to target is inside 1.0 +/- 0.1, so at a target of 80 nothing happens until the average crosses 88%, and nothing scales down until it falls under 72%. Worse, the second half of the same function re-adds every pod that has no metric yet at a usage of 0% whenever the answer would have been a scale-up, which routinely pushes the recomputed ratio back inside the dead band — so an HPA that has just added pods will refuse to add more until those pods start reporting, no matter how hot the running ones are.
The KV Cache
That LLM inference is compute-bound, so a GPU with more FLOPs serves proportionally more tokens. Decoding is memory-bandwidth bound: each token re-reads the whole weight set plus the whole KV cache, and the KV cache grows linearly with both context length and batch size until it, not the model, is what fills the GPU. Teams buy compute and get no throughput, then cut batch size to stop OOMs and lose the batching that was amortising the weight read.
The Lethal Trifecta
That tools can be risk-assessed one at a time, so a read-only server is safe to add. Every leg of the path is individually defensible: reading your files is the point, reading a web page is the point, rendering an image is a UI feature. Risk appears only in the union, and it appears the moment the third leg lands — which means the change that creates the vulnerability is usually the change that looked most harmless. The exit is also badly under-counted: a rendered Markdown image is a GET request with the attacker's data in the path, and it needs no shell, no network tool and no click.
The Rewrite Replaces Your Question
That adding conversation history helps the retriever understand a follow-up question. The retriever is never given the history and is never given the question — it is given one string produced by a separate model call that has never seen your index, and there is no fallback to the user's words when that string is wrong. Two consequences engineers do not expect. First, the rewriter resolves pronouns into the conversation's vocabulary, not the corpus's, so 'does using it extend that?' becomes a fluent sentence containing none of the terms the documents are written in. Second, more history is not better: past the turn where the user changes subject, a longer window drags the previous topic into the new query and retrieval gets worse, so the best window size is a property of where the topic shifts and not a value you can tune once.
The Slowness Is the Feature
That salting a fast cryptographic hash such as SHA-256 makes it suitable for passwords, because the salt is what stops the attack. The salt stops precomputation and stops one computation covering many accounts; it does not make a single guess cost one cycle more. What makes guessing uneconomic is the work factor — the deliberate cost of each evaluation — and a general-purpose hash is fast by design, which is precisely the property you do not want here.
The Timing Leak That Matters Skips Work, Not Bytes
That timing attacks are about comparison loops, so replacing == with a constant-time compare closes the channel. The difference a byte comparison makes is about 2.4 nanoseconds, which no filter recovers across a network at any practical sample count. The differences that are trivially readable are branches that skip work — an early return before the password hash is about 240 milliseconds, a hundred million times larger, and two requests find it. Teams add hmac.compare_digest and leave the account-enumeration oracle in place.
Transaction ID Wraparound: Why Freezing Is a Deadline
That wraparound is about running out of transaction ids — that a cluster doing a few million transactions a day is safe, and that the outage is the counter overflowing. The counter wraps harmlessly every 4 billion transactions and nothing breaks. What breaks is a row version whose xmin is older than 2^31 transactions, so the deadline is the age of the oldest unfrozen row in the oldest table, not the total count. A static table nobody writes to, an old replication slot, or one long-open transaction can hold that age up while every dashboard shows autovacuum running normally.
Trust Laundering Between Agents
That putting the untrusted work in a sub-agent contains it. Delegation is the standard containment story — a low-privilege reader agent looks at the web, an orchestrator does the privileged work — and it contains the tools while laundering the text. Whatever provenance labelling the reader had dies at the boundary, and the orchestrator's own system prompt tells it that peer output is data to act on. Worse, the payload can be written to survive the retelling, so it replicates: each infected agent reproduces it into the next one's context on its own.
What Quantization Actually Changes
That quantization is a single dial: pick INT8 or INT4, the model gets that much smaller and that much faster, and you pay for it in a little accuracy. Every part of that is wrong in a way that costs money. Weight-only INT4 shrinks the checkpoint about 2.7x, not 4x, because the embeddings and the language-model head stay in 16 bits and the per-group scales cost another 0.16 bits per weight. It speeds up decoding, where the GPU is waiting on memory, by close to the byte ratio — and it speeds up prefill by exactly nothing, because the dequantized matmul still runs at BF16 rate, so a big enough batch turns a 3x win into a measured slowdown. It does not shrink the KV cache at all; that is a separate flag. And the accuracy cost is not set by the bit width alone but by the scale granularity: the same INT4 weights are unusable per-tensor and fine in groups of 128, because a scale shared with an outlier throws away most of the sixteen levels for everyone else.
Why Prompt-Level Injection Defences Fail
That a defence with a high enough catch rate is good enough, so the work is pushing 95% to 99%. The relevant number is not the catch rate but the residual multiplied by the number of attempts, and the attacker chooses the number of attempts. Nine hundred and ninety-nine blocked injections buy nothing if the thousandth lands, which is why guardrail benchmarks and 'ignore previous instructions' regexes measure the wrong quantity. The defences that do hold change the exponent's base to zero: the untrusted text cannot reach a privileged action at all — CaMeL reports 77% of AgentDojo tasks solved with provable security against 84% undefended, and that 7-point utility cost is the actual price of the fix.
You Cannot Recall a Token You Already Issued
That calling the revocation endpoint, or clearing the session, logs a user out. It does neither for a self-contained access token. The resource server checks a signature and an expiry claim and asks nobody's permission, so a token issued before the revocation keeps working until it expires. Refresh token rotation does not close that window either — it detects, after the fact, that two parties hold the same refresh token, and the detection cannot happen until the legitimate client next refreshes.
Your bandwidth-delay product used the wrong bandwidth and the wrong delay
That the bandwidth-delay product is arithmetic you do once — the speed your link is sold at, times the number your ping prints — and that setting the socket buffer to the answer fills the pipe. Both inputs are usually wrong. The bandwidth is the narrowest hop on the path, not the link you pay for, and sizing to your own link rate on a path with a slower hop is worse than leaving the default alone. The delay has to be the unloaded minimum RTT, because throughput measured during a transfer multiplied by the RTT measured during the same transfer always returns the window you already had — so the rule certifies whatever queue you are already carrying instead of correcting it.
Z-ordering and Delta Data Skipping
That ZORDER BY (a, b, c, d) makes all four columns fast, and that a successful OPTIMIZE means skipping is now happening. The interleave splits a fixed bit budget across the keys, so each key you add widens every other key's per-file range; and a column past the first 32 in the schema has no min/max statistics at all, so Z-ordering it runs to completion and prunes nothing.
The writing queue — 6 concepts the lessons reference but nobody has written yet
These exist because a published lesson linked to them, and they are ordered by how many lessons depend on each one. That ordering is how the corpus decides what gets written next.
- Llm Linear AttentionLLM internals · 4
- K8s Cpu Manager StaticKubernetes · 2
- Sec Credential StuffingSecurity · 2
- Spark Driver MemorySpark · 2
- Tcp EcnNetworking · 2
- Tcp CubicNetworking · 1