Files
angular__angular/goldens/public-api/core/errors.api.md
T

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

219 lines
6.2 KiB
Markdown
Raw Normal View History

## API Report File for "core_errors"
> Do not edit this file. It is a report generated by [API Extractor](https://api-extractor.com/).
```ts
// @public
export function formatRuntimeError<T extends number = RuntimeErrorCode>(code: T, message: null | false | string): string;
// @public (undocumented)
export function formatRuntimeErrorCode<T extends number = RuntimeErrorCode>(code: T): string;
// @public
export class RuntimeError<T extends number = RuntimeErrorCode> extends Error {
constructor(code: T, message: null | false | string);
// (undocumented)
code: T;
}
// @public
export const enum RuntimeErrorCode {
// (undocumented)
ANIMATE_INVALID_VALUE = 650,
// (undocumented)
APPLICATION_REF_ALREADY_DESTROYED = 406,
// (undocumented)
ASSERTION_NOT_INSIDE_REACTIVE_CONTEXT = -602,
// (undocumented)
ASYNC_INITIALIZERS_STILL_RUNNING = 405,
// (undocumented)
BOOTSTRAP_COMPONENTS_NOT_FOUND = -403,
// (undocumented)
COMPONENT_ID_COLLISION = -912,
// (undocumented)
CYCLIC_DI_DEPENDENCY = -200,
// (undocumented)
DEF_TYPE_UNDEFINED = -919,
// (undocumented)
DEFER_IN_HMR_MODE = -751,
// (undocumented)
DEFER_LOADING_FAILED = -750,
// (undocumented)
DUPLICATE_DIRECTIVE = 309,
// (undocumented)
DUPLICATE_NG_MODULE_ID = 921,
// (undocumented)
EXPORT_NOT_FOUND = -301,
// (undocumented)
EXPRESSION_CHANGED_AFTER_CHECKED = -100,
// (undocumented)
EXTERNAL_RESOURCE_LOADING_FAILED = 918,
// (undocumented)
HOST_DIRECTIVE_COMPONENT = 310,
// (undocumented)
HOST_DIRECTIVE_CONFLICTING_ALIAS = 312,
// (undocumented)
HOST_DIRECTIVE_NOT_STANDALONE = 308,
// (undocumented)
HOST_DIRECTIVE_UNDEFINED_BINDING = 311,
// (undocumented)
HOST_DIRECTIVE_UNRESOLVABLE = 307,
// (undocumented)
HYDRATION_MISSING_NODE = -502,
// (undocumented)
fix(core): throw coded RuntimeErrors instead of crashing when hydration/rendering can't find an expected DOM node This started from a real production crash trace: TypeError: Cannot read properties of null (reading 'nextSibling') Traced through a minified bundle back to siblingAfter() in packages/core/src/hydration/node_lookup_utils.ts. It walks forward a fixed number of DOM siblings during hydration, based on how many the server rendered. Its only guard, validateSiblingNodeExists(), is gated behind ngDevMode and stripped from production builds. If the client DOM has fewer real siblings than the server-serialized data expects — client/server render diverged, or something outside Angular (a browser extension, an injected script) removed a node — the loop ran fully unguarded in production: currentNode went null partway through, and the next iteration's currentNode.nextSibling threw a raw, uncoded TypeError instead of a coded, debuggable one. Reproduced first, not just theorized: added a test that server- renders a @for loop with 3 items, removes 2 of them before hydration runs, and confirmed it actually throws that exact TypeError against the original code before touching anything. Fix: add a null check at the top of the loop, matching the pattern already used for the existing NG0500/NG0502 hydration checks in element.ts — the dev-mode check runs first as before (a no-op in production), and the new check is a pure safety net that only fires once that dev-mode check has already been compiled away. In dev mode this is provably dead code, so nothing about dev behavior changes. Coded as NG0501 (HYDRATION_MISSING_SIBLINGS, already existed). While investigating, found and fixed two more call sites with the exact same shape of bug — a dev-only check that leaves production completely unguarded: - navigateToNode() (same file): walks an explicit "firstChild / nextSibling" navigation path recorded for nodes that can't rely on simple sibling-walking (e.g. content right after an <ng-content> slot). Its only guard was also ngDevMode-only. Added the same production safety net, both mid-loop (the raw-crash case) and post-loop (where it could previously return null silently despite the function's return type promising a non-null RNode). New code: NG0509 (HYDRATION_MISSING_NODE_ON_PATH). - getParentRElement() (render3/node_manipulation.ts): typed its tNode parameter as always non-null, but a real production trace showed it can be null at runtime, crashing on tNode.parent with no useful information. Widened the type to TNode | null and added a guard that throws a coded error instead. New code: NG0510 (PARENT_NODE_NOT_FOUND). Unlike the other two, this one isn't gated behind ngDevMode at all in the original code — it reproduces unconditionally. Decoded the actual production minified stack trace against this source (matched every frame character-for-character) to find the real cause instead of guessing: an @if/@switch branch's content is its own embedded template with its own TView, built lazily the first time that branch renders. If an error interrupts that first pass — here, a hydration mismatch on the branch's second child, after the first child's TNode was already created — TView.firstCreatePass still gets flipped to false in render.ts's `catch` block before the error propagates, permanently marking that TView as corrupted. Unlike a component's TView (rebuilt from scratch next time via getOrCreateComponentTView()'s incompleteFirstPass check), nothing rebuilds an embedded view's TView. The next time that exact branch is selected again, its instructions read straight from the corrupted tView.data instead of creating a fresh TNode, and any node past the interruption point is still null. The real test added for this (full_app_hydration_spec.ts) exercises that whole chain for real: a hydration mismatch on an @if branch's second child, then re-entering the same branch. Confirmed it throws the exact byte-for-byte production error message ("Cannot read properties of null (reading 'parent')") without the fix, and the coded NG0510 with it. This replaces an earlier synthetic unit test that just cast a variable to null to bypass the type system rather than reproducing the actual failure. Note: a more thorough fix would rebuild the corrupted embedded TView itself (mirroring getOrCreateComponentTView()), which does make the crash disappear — but doing that surfaces a second, separate bug: the aborted first attempt's partially-created LView/DOM is never torn down, so the retried branch's content gets appended alongside leftover orphaned nodes instead of replacing them, corrupting content silently instead of crashing loudly. That's a materially bigger fix (proper LView cleanup after a mid-creation exception) and is intentionally out of scope here; this commit keeps the narrower, safe fix (a clear coded error) rather than trading a loud crash for silent data corruption. Along the way, deduplicated describeDomNode(), which existed as two near-identical private copies (one in this file's own NG0500 check, one in platform-browser's dom_renderer.ts insertBefore check) and moved it into core's hydration/error_handling.ts, shared via the private ɵdescribeDomNode export. That function was then removed from every production code path entirely, per review feedback: computing a human-readable node description is debug-oriented work that shouldn't ship unconditionally in production bundles, regardless of how cheap it is — production should get the bare coded error only, the same as everywhere else in this file. All three fixes above follow that: ngDevMode && 'message' in production, no computed description. Confirmed the removal actually shrinks output, not just assumed it: regenerated all 8 affected bundling symbol goldens, and each one shows exactly one symbol removed — "describeDomNode" — and nothing else. (cherry picked from commit 83f7695b2e4e1cab347f7817da4ae4262dade415)
2026-08-19 09:40:48 +03:00
HYDRATION_MISSING_NODE_ON_PATH = 509,
// (undocumented)
HYDRATION_MISSING_SIBLINGS = -501,
// (undocumented)
HYDRATION_NODE_MISMATCH = -500,
// (undocumented)
HYDRATION_STABLE_TIMEDOUT = -506,
// (undocumented)
IMAGE_PERFORMANCE_WARNING = -913,
// (undocumented)
IMPORT_PROVIDERS_FROM_STANDALONE = 800,
// (undocumented)
INFINITE_CHANGE_DETECTION = 103,
// (undocumented)
INJECTOR_ALREADY_DESTROYED = -205,
// (undocumented)
INVALID_APP_ID = 211,
// (undocumented)
INVALID_BINDING_TARGET = 316,
// (undocumented)
INVALID_DIFFER_INPUT = 900,
// (undocumented)
INVALID_EVENT_BINDING = 306,
// (undocumented)
INVALID_FACTORY_DEPENDENCY = 202,
// (undocumented)
INVALID_I18N_STRUCTURE = 700,
// (undocumented)
INVALID_INHERITANCE = 903,
// (undocumented)
INVALID_INJECTION_TOKEN = -204,
// (undocumented)
INVALID_MULTI_PROVIDER = -209,
// (undocumented)
INVALID_RESOURCE_CREATION_IN_PARAMS = 992,
// (undocumented)
INVALID_SET_INPUT_CALL = 317,
// (undocumented)
INVALID_SKIP_HYDRATION_HOST = -504,
// (undocumented)
INVALID_STYLE_PROP_VALUE = -318,
// (undocumented)
LOOP_TRACK_DUPLICATE_KEYS = -955,
// (undocumented)
LOOP_TRACK_RECREATE = -956,
// (undocumented)
MISCONFIGURED_INCREMENTAL_HYDRATION = 508,
// (undocumented)
MISSING_DIRECTIVE_DEFINITION = 916,
// (undocumented)
MISSING_DOCUMENT = 210,
// (undocumented)
MISSING_GENERATED_DEF = 906,
// (undocumented)
MISSING_HYDRATION_ANNOTATIONS = -505,
// (undocumented)
MISSING_INJECTION_CONTEXT = -203,
// (undocumented)
MISSING_INJECTION_TOKEN = 208,
// (undocumented)
MISSING_LOCALE_DATA = 701,
// (undocumented)
MISSING_NG_MODULE_DEFINITION = 915,
// (undocumented)
MISSING_REQUIRED_INJECTABLE_IN_BOOTSTRAP = 402,
// (undocumented)
MISSING_SSR_CONTENT_INTEGRITY_MARKER = -507,
// (undocumented)
MISSING_ZONEJS = 908,
// (undocumented)
MULTIPLE_COMPONENTS_MATCH = -300,
// (undocumented)
MULTIPLE_MATCHING_PIPES = 313,
// (undocumented)
MULTIPLE_PLATFORMS = 400,
// (undocumented)
MUST_PROVIDE_STREAM_OPTION = 990,
// (undocumented)
NG_MODULE_ID_NOT_FOUND = 920,
// (undocumented)
NO_BINDING_TARGET = 315,
// (undocumented)
NO_SUPPORTING_DIFFER_FACTORY = 901,
// (undocumented)
OUTPUT_REF_DESTROYED = 953,
// (undocumented)
fix(core): throw coded RuntimeErrors instead of crashing when hydration/rendering can't find an expected DOM node This started from a real production crash trace: TypeError: Cannot read properties of null (reading 'nextSibling') Traced through a minified bundle back to siblingAfter() in packages/core/src/hydration/node_lookup_utils.ts. It walks forward a fixed number of DOM siblings during hydration, based on how many the server rendered. Its only guard, validateSiblingNodeExists(), is gated behind ngDevMode and stripped from production builds. If the client DOM has fewer real siblings than the server-serialized data expects — client/server render diverged, or something outside Angular (a browser extension, an injected script) removed a node — the loop ran fully unguarded in production: currentNode went null partway through, and the next iteration's currentNode.nextSibling threw a raw, uncoded TypeError instead of a coded, debuggable one. Reproduced first, not just theorized: added a test that server- renders a @for loop with 3 items, removes 2 of them before hydration runs, and confirmed it actually throws that exact TypeError against the original code before touching anything. Fix: add a null check at the top of the loop, matching the pattern already used for the existing NG0500/NG0502 hydration checks in element.ts — the dev-mode check runs first as before (a no-op in production), and the new check is a pure safety net that only fires once that dev-mode check has already been compiled away. In dev mode this is provably dead code, so nothing about dev behavior changes. Coded as NG0501 (HYDRATION_MISSING_SIBLINGS, already existed). While investigating, found and fixed two more call sites with the exact same shape of bug — a dev-only check that leaves production completely unguarded: - navigateToNode() (same file): walks an explicit "firstChild / nextSibling" navigation path recorded for nodes that can't rely on simple sibling-walking (e.g. content right after an <ng-content> slot). Its only guard was also ngDevMode-only. Added the same production safety net, both mid-loop (the raw-crash case) and post-loop (where it could previously return null silently despite the function's return type promising a non-null RNode). New code: NG0509 (HYDRATION_MISSING_NODE_ON_PATH). - getParentRElement() (render3/node_manipulation.ts): typed its tNode parameter as always non-null, but a real production trace showed it can be null at runtime, crashing on tNode.parent with no useful information. Widened the type to TNode | null and added a guard that throws a coded error instead. New code: NG0510 (PARENT_NODE_NOT_FOUND). Unlike the other two, this one isn't gated behind ngDevMode at all in the original code — it reproduces unconditionally. Decoded the actual production minified stack trace against this source (matched every frame character-for-character) to find the real cause instead of guessing: an @if/@switch branch's content is its own embedded template with its own TView, built lazily the first time that branch renders. If an error interrupts that first pass — here, a hydration mismatch on the branch's second child, after the first child's TNode was already created — TView.firstCreatePass still gets flipped to false in render.ts's `catch` block before the error propagates, permanently marking that TView as corrupted. Unlike a component's TView (rebuilt from scratch next time via getOrCreateComponentTView()'s incompleteFirstPass check), nothing rebuilds an embedded view's TView. The next time that exact branch is selected again, its instructions read straight from the corrupted tView.data instead of creating a fresh TNode, and any node past the interruption point is still null. The real test added for this (full_app_hydration_spec.ts) exercises that whole chain for real: a hydration mismatch on an @if branch's second child, then re-entering the same branch. Confirmed it throws the exact byte-for-byte production error message ("Cannot read properties of null (reading 'parent')") without the fix, and the coded NG0510 with it. This replaces an earlier synthetic unit test that just cast a variable to null to bypass the type system rather than reproducing the actual failure. Note: a more thorough fix would rebuild the corrupted embedded TView itself (mirroring getOrCreateComponentTView()), which does make the crash disappear — but doing that surfaces a second, separate bug: the aborted first attempt's partially-created LView/DOM is never torn down, so the retried branch's content gets appended alongside leftover orphaned nodes instead of replacing them, corrupting content silently instead of crashing loudly. That's a materially bigger fix (proper LView cleanup after a mid-creation exception) and is intentionally out of scope here; this commit keeps the narrower, safe fix (a clear coded error) rather than trading a loud crash for silent data corruption. Along the way, deduplicated describeDomNode(), which existed as two near-identical private copies (one in this file's own NG0500 check, one in platform-browser's dom_renderer.ts insertBefore check) and moved it into core's hydration/error_handling.ts, shared via the private ɵdescribeDomNode export. That function was then removed from every production code path entirely, per review feedback: computing a human-readable node description is debug-oriented work that shouldn't ship unconditionally in production bundles, regardless of how cheap it is — production should get the bare coded error only, the same as everywhere else in this file. All three fixes above follow that: ngDevMode && 'message' in production, no computed description. Confirmed the removal actually shrinks output, not just assumed it: regenerated all 8 affected bundling symbol goldens, and each one shows exactly one symbol removed — "describeDomNode" — and nothing else. (cherry picked from commit 83f7695b2e4e1cab347f7817da4ae4262dade415)
2026-08-19 09:40:48 +03:00
PARENT_NODE_NOT_FOUND = 510,
// (undocumented)
PIPE_NOT_FOUND = -302,
// (undocumented)
PLATFORM_ALREADY_DESTROYED = 404,
// (undocumented)
PLATFORM_NOT_FOUND = -401,
// (undocumented)
PROVIDED_BOTH_ZONE_AND_ZONELESS = 408,
// (undocumented)
PROVIDER_IN_WRONG_CONTEXT = -207,
// (undocumented)
PROVIDER_NOT_FOUND = -201,
// (undocumented)
RECURSIVE_APPLICATION_REF_TICK = 101,
// (undocumented)
RENDERER_NOT_FOUND = 407,
// (undocumented)
REQUIRE_SYNC_WITHOUT_SYNC_EMIT = 601,
// (undocumented)
REQUIRED_INPUT_NO_VALUE = -950,
// (undocumented)
REQUIRED_MODEL_NO_VALUE = 952,
// (undocumented)
REQUIRED_QUERY_NO_VALUE = -951,
// (undocumented)
RESOURCE_COMPLETED_BEFORE_PRODUCING_VALUE = -991,
// (undocumented)
RUNTIME_DEPS_INVALID_IMPORTED_TYPE = 980,
// (undocumented)
RUNTIME_DEPS_ORPHAN_COMPONENT = 981,
// (undocumented)
SIGNAL_WRITE_FROM_ILLEGAL_CONTEXT = 600,
// (undocumented)
TEMPLATE_STRUCTURE_ERROR = 305,
// (undocumented)
TYPE_IS_NOT_STANDALONE = 907,
// (undocumented)
UNEXPECTED_ZONE_STATE = 909,
// (undocumented)
UNEXPECTED_ZONEJS_PRESENT_IN_ZONELESS_MODE = 914,
// (undocumented)
UNINITIALIZED_LET_ACCESS = 314,
// (undocumented)
UNKNOWN_BINDING = 303,
// (undocumented)
UNKNOWN_ELEMENT = 304,
// (undocumented)
UNSAFE_ATTRIBUTE_BINDING = -910,
// (undocumented)
UNSAFE_VALUE_IN_RESOURCE_URL = 904,
// (undocumented)
UNSAFE_VALUE_IN_SCRIPT = 905,
// (undocumented)
UNSUPPORTED_PROJECTION_DOM_NODES = -503,
// (undocumented)
VIEW_ALREADY_ATTACHED = 902,
// (undocumented)
VIEW_ALREADY_DESTROYED = 911,
// (undocumented)
VIEW_DESTROYED_INSERT_ERROR = 922,
// (undocumented)
VIEW_DESTROYED_MOVE_ERROR = 923
}
// (No @packageDocumentation comment for this package)
```