Replacement has incorrect status messages

[EronWright]

What happened?

I observe that Pulumi emits incorrect status messages when doing a replacement of a Kubernetes resource. In particular, the last message pertaining to the "replacement" object (as it is created) is later shown on the "original" object (as it is deleted).

Example

For example, observe the erroneous "Waiting" messages in the following sequence. Note that I am using --non-interactive for clarity, and that Pulumi is using delete-after-replace semantics in this example.

 ++ kubernetes:core/v1:Pod autonaming-test creating replacement (0s) [diff: ~metadata]
 ++ kubernetes:core/v1:Pod autonaming-test creating replacement (0s) [diff: ~metadata];
 ++ kubernetes:core/v1:Pod autonaming-test creating replacement (0s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be scheduled
 ++ kubernetes:core/v1:Pod autonaming-test creating replacement (0s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be initialized
 ++ kubernetes:core/v1:Pod autonaming-test creating replacement (0s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready
@ updating....
 ++ kubernetes:core/v1:Pod autonaming-test created replacement (1s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready
 +- kubernetes:core/v1:Pod autonaming-test replacing (0s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready
 +- kubernetes:core/v1:Pod autonaming-test replaced (0.00s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready
 -- kubernetes:core/v1:Pod autonaming-test deleting original (0s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready
@ updating.....
 -- kubernetes:core/v1:Pod autonaming-test deleted original (1s) [diff: ~metadata]; Waiting for Pod "test-namespace-4d5e71b3/autonaming-test" to be ready

Output of pulumi about

❯ pulumi about
CLI          
Version      3.94.2
Go Version   go1.21.4
Go Compiler  gc

Host     
OS       darwin
Version  13.5.1
Arch     arm64

Additional context

I believe that the root cause is related to the fact that the "original" object and "replacement" object have the same resource URN. As the CLI emits a log line for each engine event, it repeats the most recent diagnostic message for the associated resource. The "replacement" object's await logic produces the diagnostic messages, but the "original" object doesn't produce any diagnostic message and so the last message of the former object is repeated.

Two fixes come to mind:

1. Clear the diagnostic message after the await logic completes for a given resource, and/or
2. Emit a diagnostic message in the await logic for deletions, e.g. "Waiting for finalization..."

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).