You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(trace): simplify how construct traces get built (#34355)
This change is motivated by the tree metadata containing a `parent` pointer that used to be stripped before writing it to disk in `tree.json`. I removed the `parent` pointer because shouldn't be in this data structure at all.
The TreeMetadata `parent` pointer was being used to build a `ConstructTrace` for the purposes of reporting template validation errors, so that code had to be refactored as well. It was doing a complicated dance that I honestly didn't quite understand going up and down the construct tree trace and holding cached copies of various data structures in memory.
I removed the dependency of the trace reporting on `TreeMetadata` and replaced it with a path traversal from the root of the construct tree, and progressively building the `ConstructTrace` from the constructs we find along the way: first building a chain of `ConstructTrace` objects without `child` and `location` information, and then adding it on later.
One note on what's left here:
- As far as I can tell we are peeling apart a stack trace from the lowest-level `CfnResource` into a different single frames, to be reported in the `ConstructTrace`. I *think* I did a faithful conversion, but what I have only works if child constructs are always created in constructors. Our counting of stack frames will be off by one for every method call involved (in other words, if more than 1 stack frame separates 2 levels in the construct tree).
I'm not fixing this right now because that's not what I want to focus on, but this could/should probably be a backlog item?
------
As an example of the latter, let's say this construct tree:
```
StaticWebsite
|
+-- Bucket
|
+--- CfnResource <-- stack trace only available here
```
The way we will do this is we'll take the stack trace from `CfnResource`, and use it as follows:
- `stackTrace[0]` -> that must be where CfnResource is created
- `stackTrace[1]` -> that must be where Bucket is created
- `stackTrace[2]` -> that must be where StaticWebsite is created
The above assumptions hold for the following code:
```ts
// static-website.ts
class StaticWebsite {
constructor() {
new Bucket(this, 'Bucket');
}
}
// app.ts
new StaticWebsite();
```
But *don't* hold for the following code:
```ts
// static-website.ts
class StaticWebsite {
constructor()
this.createStaticHtmlBucket();
}
private createStaticHtmlBucket() {
new Bucket(this, 'Bucket');
}
}
// app.ts
new StaticWebsite();
```
Because the initialization of `StaticWebsite` now comprises 2 stack frames instead of 1.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
0 commit comments