c61bce3e41
The prior code was a little too aggressive in rejected undefined properties, because it assumed any occurrence indicated a resource that was unavailable due to planning. This is a by-produt of our relatively recent decision to flow undefineds freely during planning. The problem is, it's entirely legitimate to have undefined values deep down in JavaScript structures, entirely unrelated to resources whose property values are unknown due to planning. This change flows undefined more freely. There really are no negative consequences of doing so, and avoids hitting some overly aggressive assertion failures in some important scenarios. Ideally we would have a way to know statically whether something is a resource property, and tighten up the assertions just to catch possible bugs in the system, but because this is JavaScript, and all the assertions are happening at runtime, we simply lack the necessary metadata to do so. |
||
|---|---|---|
| .. | ||
| nodejs | ||
| proto | ||
| README.md | ||