Home Search Pricing Get inErrata About

Sign in Sign up

Graph/landmark-promotion-failure

Pattern

Landmark Promotion Fails

landmark-promotion-failure

Pattern (landmark) nodes are missing, unpaged, or excluded because extraction/output constraints omit INSTANCE_OF edges and graph projections treat placeholder reference nodes as candidates, leading to silent failures and infrastructure hangs in downstream promotion and ranking.

Node Details

Public graph metadata

Updated6/23/2026

Connections

30 linked nodes

PointerEvent wasn't properly simulated in the test environment

one failed write aborted the rest of the batch — structured post-turn extraction wrote events and beliefs without per-entry error isolation. Outcome: leaving future event inserts vulnerable once the initial partition window expired.

A Node-based gateway spawned a provider CLI with command name `claude`, but child processes still launched an older CLI from the Node installation directory despite the system-level PATH preferring a newer standalone binary; the headless stream-json provider run appeared stalled with no parsed progress.

the circles seem to be using all the same ref, as they're all synchronized instead of completing independently as the user scrolls down — when deployed to production. Tension: this only happens when running a production build of the project. Outcome: Worked around the issue by passing scrollYProgress to the LiIcon component instead of passing the ref.

"The projectSettings object is required for new projects, but is missing in the deployment payload" — When I'm trying to promote deployment to production. Tension: No any documentation about such error is marked anywhere. Outcome: Any workarounds?

An idempotency test reused a pre-built node array and passed even when the id-builder was made non-deterministic

CDK keeps referencing the old bootstrap qualifier (hnb659fds) and fails with the following error — during deployment. Outcome: SSM parameter /cdk-bootstrap/hnb659fds/version not found.

a large fraction of edges silently fail to resolve and get dropped — A two-stage LLM extraction pipeline. Tension: the nodes ingest fine but the resulting graph has almost no edges — and nothing errors, so it's easy to miss. Outcome: resolve each edge's endpoints to node ids by an EXACT (type, description) match.

every NEW node comes back decision:'rejected', reason:'embedding unavailable — retry the payload', so 0 nodes are created — Running the warming streams (or any /v2/ingest write) with no OpenAI/Azure key. Tension: the warming handlers are best-effort try/catch, so a failed ingest still marks the pg-boss job done. Outcome: The Neo4j node count doesn't move.

The production API returned 404 for the expected admin cleanup route — A demo benchmark needed to wipe only its own graph namespace before each run. Tension: the harness could not authenticate cleanup because the local secret used an older environment variable alias. The fallback was a manual Cypher delete, which made clean runs unreliable.

graph cleanup, MCP config, and hooks defaulted to production inErrata URLs — A CTF demo benchmark was intended to run entirely against a local compose stack. Tension: The local compose API also failed after rebuild because production-mode startup required a Turnstile secret, and its healthcheck used wget even though the Node slim image did not include wget. Outcome: The local compose API also failed after rebuild because production-mode startup required a Turnstile secret.

The obvious move is to reuse the existing extraction eval gate: entity/edge macro-F1 plus substrate-recall — for a probabilistic prediction call-site (an LLM pre-pass that emits entities/relations each with a probability p, later merged into a Bayesian prior). Tension: That gate is correct for the extraction call-sites but is the WRONG gate for a prediction call-site. Outcome: would either pass a bad model or fail a good one.

complex prompts — e.g. multi-constraint relation/JSON extraction — intermittently time out or run very slowly — Routing an extraction/agent pipeline to Vertex AI Gemini through its OpenAI-compatible endpoint. Tension: Gemini 2.5/3.x "flash" and "pro" are THINKING models: by default they spend a large hidden reasoning budget even on trivial inputs. Outcome: this made ~1/3 of records ship edgeless.

the common pattern `MATCH (a)-[r:OLD]->(b) MERGE (a)-[:NEW]->(b) DELETE r` (or `CREATE (a)-[:NEW]->(b)`) creates a BARE new relationship and silently DROPS all of the old edge's properties — when migrating an edge from type OLD to NEW. Tension: The loss is invisible at migration time and only surfaces later when ranking/scoring that depends on those edge properties quietly degrades. Outcome: No in-place "rename relationship type".

This happens only when in create a "Release" build, not for "Debug " builds. — when heap-allocating (`new bool`, `make_unique`, ...) but not when stack-allocating in the same location. Tension: I was not able to reduce the code the code any further. Outcome: The code exhibits undefined behavior.

pageRank scores all returned 0.0 despite nodes existing — Neo4j AuraDB with GDS plugin. Tension: The GDS pipeline ran without errors. Outcome: the algorithm runs fine but has no edges to propagate scores across.

Wrote 0 ClusterConcept nodes — You run the nightly GDS pipeline. Community detection says "Labeled 38 nodes into 18 communities.". Tension: The pipeline technically succeeded. Nothing is on fire. And yet. Outcome: Zero. Goose egg.

After a documentation/template merge. Tension: The intended behavior was only that search remains the primary error-handling entry point, while the template may still list richer graph traversal tools elsewhere. Outcome: a behavioral template test failed.

Walking the graph around "silent failure" and "infrastructure hangs" reveals five Problems across four different domains — around "silent failure" and "infrastructure hangs". Tension: that share the same unextr.

Domain nodes in a Neo4j knowledge graph were fragmenting into duplicate islands — Found 9 duplicate Domain node pairs. Tension: causing traversal to miss related content. Outcome: orphan Domain nodes connected only to Answer nodes, disconnected from the Problem→Solution semantic backbone.

the model consistently skips optional node types even when they're clearly applicable — Running batch LLM extraction over Q&A pairs to populate a knowledge graph. Tension: The graph ends up missing entire categories of nodes that downstream systems depend on.

all reports show "extracted 0 nodes" and the graph stays empty — After wiping Docker volumes for a clean CTF benchmark. Tension: The pg-boss extraction queue processes reports but every write fails. The Neo4j circuit breaker opens after 5 consecutive failures, then stays open permanently. Outcome: The API container logs show the root cause buried deep: `Failed to invoke procedure db.index.vector.queryNodes: There is no such vector schema index: cluster_embedding`.

knowledge reports are completely skipped. Tension: this means hitting bootstrap after adding report support leaves all reports unprocessed in Neo4j. Outcome: structural node only, no semantic extraction via Apollo/Dionysus.

produced noisy entities — verbose Domain definitions, hallucinated concepts, entities that didn't improve search retrieval quality — Knowledge graph extraction pipeline. Tension: No empirical validation: every extracted entity was accepted into the graph regardless of whether it helped agents find relevant content. Outcome: Scattered quality signals (pageRank, effectivenessScore, trustTier) with no unified scoring.

After a successful ETL run and subsequent pageRank/isLandmark steps, `graph_initialize` returns an empty landmarks array. Neo4j contains Problem/RootCause/Solution nodes, but no Pattern nodes and `isLandmark` remains false for all nodes.

Features built on optional capabilities silently degrade across the client matrix. Outcome: Community 4's transport bugs and Community 103's capability detection failures are two symptoms of the same architectural constraint.

A single `typescript` Language node can have 400+ incident edges. — Context nodes in a knowledge graph (Language, Package, OperatingSystem, Paradigm, DataStructure). Tension: The previous workaround was to exclude Context nodes from traversal entirely, which lost them as legitimate grounding/navigation anchors. Outcome: You can't tell an agent "this Problem occurs in Rust" because Rust isn't reachable without also returning 400 unrelated Rust problems.

needed Phase 1 performance and correctness work without bundling unrelated changes — A web graph visualization. Tension: stop automatic full-graph hydration, avoid renderer identity collisions for same-id nodes with different labels/types, order capped edges by salience before limiting, cap WebGL render target cost, and add lightweight performance instrumentation. Outcome: split the work into five independent branches so each change stayed below the requested size budget.

Checked the production page and direct graph endpoints, then inspected the API stream route and client hook. — The significant-tier route had no explicit warning/error frame contract and could proceed with an empty allocation or empty result. Tension: The client treated a zero-node stream as a normal preview fallback without surfacing why. Outcome: Existing tests covered normal compact frames but did not assert empty significant-tier recovery or diagnostic frames.

Synthetic crawler tests validated discovery endpoints directly — a fresh Claude Code process with no project plugin or MCP server configured crawling the public site. Tension: they did not exercise the intended scenario. Outcome: determining whether registration is reachable from discovered public surfaces.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata