Add the name of the current type to the exception we throw in an unsupported case.#46183
Conversation
There was a problem hiding this comment.
my supposition is that somehow the outer wrapping group item got triggered, causing us to eventaully call into GetChangedDocumentAsync below. That's the only thing i can think of that would be possible.
The change in this file is to make us resilient to someone calling that. The change below is to narrow down who is actually throwing if it's something else.
The two pieces of information i'm adding are to try to find out if that's the case.
There was a problem hiding this comment.
Are we still going to hit GetChangedDocumentAsync when running into this scenario you described with this change?
There was a problem hiding this comment.
Are we still going to hit GetChangedDocumentAsync when running into this scenario you described with this change?
So one of two thigns is true:
- Somehow, someone called GetOperations on a 'code action with nested actions' unexpectedly. If this it eh case, then the override of InnerInvoke here makes us resilient.
- Someone was calling into a CodeAction that isn't well behaved and is throwing in GetChangedDocument. If this is the case, then adding the "GetType().FullName" to the exception will tell us which code action is not well behaved.
7faf2fd to
7339398
Compare
We've received a customer report of this exception being thrown. However, it's in a scenario where many code actions are created. Adding specific information to the exception to help track down which may be at fault as we cannot repro this ourselves.