-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent AnonymousKernelCommands from ending up inside serialized KernelEvents #2888
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -160,7 +160,6 @@ internal override Task HandleAsync( | |
switch (command) | ||
{ | ||
case AnonymousKernelCommand: | ||
return base.HandleAsync(command, context); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this could lead to a deadlock if the anonymous command targets the proxy. For sure this will throw exception as it will try to forward the command on the sender and will fail at serialization. This looks like a test gap to pinpoint There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes this PR is fixing one specific case where we were serializing AnonymousKernelCommand (inside SubmissionParser.cs). But the larger test gap has not been addressed yet - I have included this in #2884 and plan to address that in a follow up PR. |
||
case DirectiveCommand: | ||
return base.HandleAsync(command, context); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intended to be generally true, so not specific to
DiagnosticsProduced
. The internal command (AnonymousKernelCommand
in this case, but it could as easily be one of the public command types) is an implementation detail that the external caller shouldn't have to be aware of.It might be useful to add another similar test for the split between subkernels because the same should be true for, for example:
This should apply to command types including various language service commands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So looks like this invariant is not satisfied for all events in the above case. For example,
CodeSubmissionReceived
,CompleteCodeSubmissionReceived
,ReturnValueProduced
events for the repro code you shared above point back to the per-languageSubmitCode
commands created internally for C# and F# respectively. Only the finalCommandSucceded
event points back to the originalSubmitCode
command.If I change the submission to the following then interestingly, the
DiagnosticsProduced
event for the erroneous line points to the F#-specificSubmitCode
command with codesome error
. However, the line spans in theDiagnosticsProduced.Diagnostics
reflect the spans in the original submission.This may be reasonable considering that the inner commands reflect the expected command splitting behavior - however, it also seems like internal implementation details of the callee are bleeding through to the caller.
If this is unexpected, I can log a separate bug to a) fix the behavior and b) add tests to ensure that inner commands are never exposed to the caller. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jonsequitur Btw the current PR should be ready to merge. The above issue needs more investigation / follow-up and I'd prefer not to hold up the current PR for that. Please approve if you agree :) Thanks!