refactor(core): show bounded paths in hydration errors - #70249

I'm afraid this change would bring too much noise to the error message, especially for deeply nested hydration issues.

Do you have a concrete example where such additional debug information was useful ?

Thanks, that is a fair concern. I pushed 60d820c69a to avoid rendering the full ancestry tree.

A concrete ambiguous case is now covered by the integration test. The template contains two otherwise-identical branches:

<section aria-label="Account">
  <div class="name"><b>Alice</b></div>
</section>
<section aria-label="Billing">
  <div class="name"><b>Bob</b></div>
</section>

If the <b> in Billing is replaced by a <span>, the compact local snippets only show:

<div class="name">
  <b>…</b>  <-- AT THIS LOCATION
</div>

and:

<div class="name">
  <span>…</span>  <-- AT THIS LOCATION
</div>

That identifies the mismatch, but not which identical branch contains it. The revised output keeps those local snippets and adds only this bounded path:

DOM path: <app> > ... > <section aria-label="Billing"> > <div class="name"> > <b>

The path displays at most four real nodes: the component host plus the three nodes closest to the mismatch. Any middle ancestry is replaced with ..., so the output size stays bounded for deeply nested templates. The test also covers non-element mismatch nodes so text or comment locations do not produce an empty path.

Would this bounded format address the noise concern?

I think the current proposition lacks in readability. Wondering if we could do something like :
But where would cap the number of parent elements we're mentionning.

DOM path:
<app>
 └─ ...
    └─ <section aria-label="Billing">
       └─ <div class="name">
          └─ <b>

Also Maybe there is something the devtools could provide, if we give it the correct info.

Thanks, I updated the output to use the vertical tree format:

DOM path:
<app>
 └─ ...
    └─ <section aria-label="Billing">
       └─ <div class="name">
          └─ <b>

The cap remains four real nodes in total: the component host plus the three nodes closest to the mismatch. The ... line does not count toward that limit. Paths with four or fewer nodes are displayed without the ellipsis. This keeps the output size bounded while preserving enough local context to distinguish the otherwise-identical branches in the test.

I also checked the existing DevTools flow. Core already attaches the exact expectedNodeDetails and actualNodeDetails strings to the nearest component host via __ngDebugHydrationInfo__; the DevTools backend passes those fields through and the UI renders them in <pre>. Therefore this more readable format is automatically available in DevTools as well. Pointing DevTools at the exact non-component DOM child would require a separate core/protocol change, so I have not expanded this PR in that direction.

Does the four-node cap look reasonable to you?