Certain @let values can mimic internal data structure, breaking basic runtime logic

Which @angular/* package(s) are the source of the bug?

core

Is this a regression?

Yes

Description

Before hydration and using signals my code worked. I refactored it to use signals and incremental hydration and it broke. The error message was not really meaningful: Cannot add property i18nNodes, object is not extensible

I use apollo-angular which freezes every object in its state and results. The state cannot be modified.

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

Cannot add property i18nNodes, object is not extensible

The line where the error has happened is https://github.com/angular/angular/blob/4491704fbaec02db8eec5845ffbb200dbf2a0bf6/packages/core/src/hydration/i18n.ts#L660

Please provide the environment you discovered this bug in (run `ng version`)

NX 20.3.0
Angular 19.0.5
Angular SSR 19.0.6

Anything else?

Workaround:

Unfreeze the object using some hacky js code: const unfrozenObj = JSON.parse(JSON.stringify(obj));

Possible solutions:
Check before trying to set the values if the object is frozen using: Object.isExtensible(object).

Throw an error that the state is not extensible and provide some information on the current component which has the error.
Show a warning during development and provide some information on the current component which has the error. In production mode ignore it.
Ignore setting the values without any warning.

I am very happy to code and make a PR on any of the solutions if the Angular team has decided.

Hi, could you please provide a stackblitz reproduction or a minimal project on a github repo. Thank you.

I was not able to reproduce it, but in my lView list I can see my array that is frozen. I don't know how to put data there, I've been trying for more than an hour now. I have tried @let @if @for.

In my original code I use a state key to store the data. That is not frozen. Then the library updates it with the frozen data. Then the hydration runs.

EDIT: Here is the code that I made for reproduce the error which was not successfully reproduced: https://stackblitz.com/edit/stackblitz-starters-v39odskh?file=src%2Fapp%2Fapp.component.ts

My HTML in the original code looks like this:

@let list = elements();
@if (unrelatedHttpCallWithOwnTiming()) {
  ...
  @if (anotherUnrelatedHttpCallWithOwnTiming()) {
    ...
    @if (relatedIfToList() && ...) {
      <div>
        <!-- If I move the let here the error goes away. -->
        @for (element of list; track element.id) {
          <subcomponent [element]="element" />
        }
      </div>
    }
    @if (!relatedIfToList() && ...) {
      <div>
        <!-- If I move the let here the error goes away. -->
        @for (element of list; track element.id) {
          <subcomponent [element]="element" />
        }
      </div>
    }
  }
}

If I move the @lets next to the usage, the error goes away. So being deeply nested puts the array into the lView array.

~~Probably this optimization hides my let declaration in the stackblitz example.~~

I have found the bug. If the data in the @let is an array, ~~or an object with a 6 key,~~ then it finds it as a hydration data in this line:

angular/packages/core/src/hydration/i18n.ts

Line 650 in 4491704

const hydrationInfo = lView[HYDRATION];

The cleanup is referenced here:

angular/packages/core/src/hydration/cleanup.ts

Line 99 in 412ac30

cleanupI18nHydrationData(lView);

So this check has the error:

angular/packages/core/src/hydration/cleanup.ts

Line 106 in 412ac30

} else if (isLView(lView[i])) {

The isLView function has the error:

angular/packages/core/src/render3/interfaces/type_checks.ts

Line 19 in 412ac30

    
           export function isLView(value: RNode | LView | LContainer | {} | null): value is LView {

Every array that is stored in a LetDeclaration is considered as an LView.
If the array has a 6th element, then the error happens.

Possible solution:
Mark LViews or LetDeclarations to be able to distinguish the two arrays.

Marking every LView would be a lot of memory.
Marking every LetDeclaration can be a solution, however it would make the code very unreadable.
Making the LetDeclaration data in the LView to appear as an object can be a solution that provides readable code.

A minimal repro :

@Component({
  selector: 'app-root',
  template: `
    @let list = [0, {}, 0, 0, 0, 0, 1];
    <!-- index 6 is important for repro-->
    @if (true) { {{ list }}}
  `,
})
export class AppComponent {}

For the Let Declaration to be mistaken for a LView, index:1 must be an object.

@alxhub

@alxhub also brought up an idea to use T data structures (TNodes) to identify the type of value stored in a given LView slot. This would require some refactoring around existing places where isLView and isLContainer are used to bring T data structure where needed.

@AndrewKushnir

@AndrewKushnir I agree on the first option, as it fits into the current code and has the less impact.

Adding a new condition to every isLView check would impact the performance a lot. These checks happen during initial rendering.

If you agree on the solution I am happy to create the PR. I have found a bug and I would love to fix Angular. 😍

@csutorasr

If you agree on the solution I am happy to create the PR. I have found a bug and I would love to fix Angular. 😍

@csutorasr thanks for your interest in contributing to Angular. We still need to figure out the best path forward and some of the options (using T data structures) might require complex refactoring. We'll discuss possible solutions with the team and will keep this thread updated.

fix(core): avoid confusion between let value and internal data struct…

In lieu of opening a new issue this is likely a related case when having a @let inside a content projection slot produces the error Error: NG0502: During serialization, Angular was unable to find an element in the DOM:

<comp>
  @let var = val;
</comp>

Moving the let outside the slot fixes the issue.

@griest024

@griest024 Is this all the code that you have? Or are there any other code in the projected html? If there's none, then no components can use the var because there's nothing in the scope of that element.

I don't think it is related and I close this issue as it was resolved by the PR.

Oh, sorry it was not resolved by the PR that is mentioned, but further changes to the code had resolved it.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

Navigation Menu

Repository navigation

Certain `@let` values can mimic internal data structure, breaking basic runtime logic #59504

Which @angular/* package(s) are the source of the bug?

Is this a regression?

Description

Please provide a link to a minimal reproduction of the bug

Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run `ng version`)

Anything else?

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Certain @let values can mimic internal data structure, breaking basic runtime logic #59504

Description

Which @angular/* package(s) are the source of the bug?

Is this a regression?

Description

Please provide a link to a minimal reproduction of the bug

Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run ng version)

Anything else?

Activity

JeanMeche commented on Jan 13, 2025

csutorasr commented on Jan 13, 2025

csutorasr commented on Jan 14, 2025

csutorasr commented on Jan 14, 2025

csutorasr commented on Jan 14, 2025

JeanMeche commented on Jan 14, 2025

9 remaining items

AndrewKushnir commented on Jan 16, 2025

csutorasr commented on Jan 16, 2025

AndrewKushnir commented on Jan 17, 2025

griest024 commented on Oct 3, 2025

csutorasr commented on Oct 27, 2025

csutorasr commented on Oct 27, 2025

angular-automatic-lock-bot commented on Nov 27, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Certain `@let` values can mimic internal data structure, breaking basic runtime logic #59504

Please provide the environment you discovered this bug in (run `ng version`)