In the realm of asynchronous programming, managing stateful update notifications presents a daunting challenge. In our ongoing exploration, we scrutinize a solution that aims to address this challenge by seamlessly handling multiple requests for work while ensuring that only the last one triggers a notification. However, beneath the surface of this endeavor lies a tangle of legal intricacies and logical pitfalls, urging us to dissect, refine, and ultimately fortify our approach.

Adding State to the Update Notification Pattern, Part 2

by Raymond Chen

From the article:

Last time, we started looking at solving the problem of a stateful but coalescing update notification, where multiple requests for work can arrive, and your only requirement is that you send a notification for the last one. Any time a new request for work arrives, it replaces the existing one.

One attempt to fix this is to check if the work is already in progress, and if so, then hand off the new query to the existing worker. We are using winrt::fire_and_forget, which fails fast on any unhandled exception. This saves us from having to worry about recovering from exceptions. (At least for now.)