Skip to content

CmdPal: add an in-place adaptive card updater - #50211

Open
Mike Griese (zadjii-msft) wants to merge 7 commits into
mainfrom
user/migrie/f/incremental-cards
Open

CmdPal: add an in-place adaptive card updater#50211
Mike Griese (zadjii-msft) wants to merge 7 commits into
mainfrom
user/migrie/f/incremental-cards

Conversation

@zadjii-msft

Copy link
Copy Markdown
Member

Adds a library for in-place updating of our adaptive cards, so that our performance graphs don't flicker anymore.

Warning

Here be basilisks!

This entire library is maintained by LLMs. Humans didn't write the code, and no human actually owns this code.

This library was generated to experiment with the big picture problem "can we update the content of a rendered Adaptive Card without replacing the entire card?"

I would fully suspect that this is not the correct approach to solve this problem. It is an approach however, and it's one that works well enough to continue experimenting with.

Everything in Microsoft.CmdPal.AdaptiveCards.IncrementalRendering was LLM generated and I admittedly, only very lightly reviewed it. I hate myself, but it does work.

I don't want to pontificate too highly on the state of everything. We're going to need to do more experimentation with projects that are largely LLM maintained1. CmdPal is most definitely not that. It remains human owned.

This is a relatively small and self-contained sub-project that we can pilot what that means for the rest of the broader project.

Closes #46362

Footnotes

  1. much to my own chagrin.

As it turns out, the robots are unbelievably stupid. When they build our projects to verify their changes, they will often just build the CS proj that they changed rather than building it in the context of the solution. On the surface, this feels like a good idea. Only build the thing that changed.

However, because they're not building it in the context of a solution, the MSBuild variable `$(SolutionDir)` doesn't get expanded to the actual directory of the solution. Instead, it just gets treated as the *path to the project*. This creates terrible recursive loops where the output of a project gets dumped relative to the project itself, and then that gets taken as input to the project's package outputs, and eventually you're gonna end up with a max path overrun.

The very easy solution here is to just replace `$(SolutionDir)` with `$(RepoRoot)`.

If we use that variable, then the dumb robots will still get the correct value for that variable when they build just a project. And for all the actual humans, everything will work exactly as it did before.
@zadjii-msft Mike Griese (zadjii-msft) added Product-Command Palette Refers to the Command Palette utility CmdPal-HostUX CmdPal - Dock Issues related to the Command Palette Dock CmdPal - Performance monitor 0.102 labels Aug 28, 2026
@github-actions github-actions Bot added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 28, 2026
@github-actions

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

0.102 CmdPal - Dock Issues related to the Command Palette Dock CmdPal - Performance monitor CmdPal-HostUX Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Product-Command Palette Refers to the Command Palette utility

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Graphs in performance monitor flicker on update

2 participants