@lemon-agent-27707 @tall-librarian-49374 looking for thoughts on something. Currently I am wiring up the Pulumi Automation preview to our internal CD app and we're looking to preserve that pulumi log output for historical purposes. So we'll probably hook into that

OnOutput

delegate to capture those logs. But currently if you look here you'll see that the

OnOutput

delegate is only invoked when the StdOut stream is written to and not when StdErr is written to. I believe I just mimicked the behavior from the other SDKs when I did that.. but that means that if their is an error it will only be reflected in the resulting exception and not in our historical logs that we built from the

OnOutput

delegate. Do you think that maybe we should have a second delegate for

OnError

, or maybe

OnOutput

should be invoked for both?

Hey! I definitely think this is worth doing, opened https://github.com/pulumi/pulumi/issues/6511 to track.

Yea I can do that tomorrow!

Little change of plans, I think we’d rather avoid the break. I updated the issue description, adding a delegate for

OnStderr

for C# should be all that needs to happen.

Would we want to name it

OnError

instead then? To keep with the

OnOutput

naming convention? Seems weird to go half way with the names, if you’re gonna break it later to re-name one why not do both later - right?

Hey everyone! Author of that PR (6513) here, I only saw this thread now, so hopefully I did not waste anyone's time

I think to get it to write to StdErr you’d want to cause one of the pulumi exceptions, such as stack already exists exception

I'll see if that would trigger it, I tried for example using

Config

and requiring a value that does not exist, but even that error would end up being written to the Stdout

Oh, huh. Well then I don't think required resource parameters will do it either. One of the pulumi guys might have a better example

From what I see, currently all of the normal Pulumi output is being written to Standard output, including errors

I would say generally that if Pulumi has incorrect or buggy stderr hygiene in some places that we should consider it a bug. I would not want to design this API around that bug. stdout and stderr refers the the CLI process which will surface output form other processes (language runtime, provider plugins).

I think this should then be ok as it is (with some minor naming changes) and then we can create another issue regarding the standard error hygiene for the CLI, which should then propagate through the automation API. How does that sound?

I added a little more context in the issue around why I would like to avoid calling this handler

OnError

and be clear about the fact that it is actually

OnStandardError

. https://github.com/pulumi/pulumi/issues/6511

Is it okay to name

OnOutput

as

OnStandardOutput

as well?

I guess since the C# SDK is relatively new and unlikely to have heavy usage (apart from you fine folk) just yet I would be okay with taking the breaking change to rename

OnOutput

to

OnStandardOutput

. I would request that you also update the usage in the examples if going with

OnStandardOutput

: https://github.com/pulumi/automation-api-examples#net-examples 🙏

will do!