| Hm, that is bad and something I did not think about when implementing the support for Deferred. The problem here is that the file/line is not included in the serialization of the deferred value into the catalog. Thus when it is resolved (i.e. called) on the agent side it has lost all of the context in which it was created. To fix this, when an instance of Deferred is created it needs to look on the puppet stack to get the caller's location. These two values must then be encoded in the Deferred instance, and then serialized. Then the logic that performs the call must make use of the file/line information which probably involves catch and re-raise-or-wrap depending on type of error being raised. Since this affects the serialization a decision to include file/line must depend on what the agent accepts. A compromise could be to show file/line for the resource attribute for which the deferred is resolved (IIRC those are available in the catalog). This may not be correct if the deferred is nested in some other structure, but perhaps better than nothing. Doing that would not require messing with the serialization protocol. |
