▸case-19 I need to process a database table with tens of millions of rows, row by row, doing an async
operation on each one as it arrives, without ever holding the full result set in memory at once.
What C# language/BCL construct is designed for exposing and consuming a sequence like this
asynchronously, one item at a time? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-23 Take a look at this Python coroutine and tell me if it follows good asyncio practice:
```python
async def fetch_user(user_id):
result = await db.fetch_one(user_id)
notify(user_id) # a coroutine function; not awaited here
return result
``` | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-08 Our team is adding a brand-new public method to a service class. It performs an async lookup and
returns Task<Order>. A teammate's first draft names it `Order()`. What naming issue does that
draft have per our team's async coding convention, and what should the method be renamed to? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-16 Our console app's Main method currently does this to get results from two async startup
routines: `var config = _loader.LoadConfigAsync().GetAwaiter().GetResult();` followed later by
`var status = _healthCheck.RunAsync().Result;`. Since C# allows an async Main method, is there a
cleaner way to get both of these results in Main, and what would you change? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-07 We have a synchronous validation method today: `public bool Validate(Order order)`. We need to
change it to call an async fraud-check API partway through, so it has to become awaitable while
still reporting true/false back to its caller. What should its new return type be, and would
declaring it `async void` be an acceptable way to keep the signature visually simple? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-22 Review this Node.js function for async best practices:
```javascript
async function loadUser(id) {
const user = await db.users.findById(id);
logAccess(id); // returns a Promise; not awaited here
return user;
}
```
What, if anything, needs fixing? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-21 Please review this C# method for our code-quality checklist:
```csharp
public class OrderProcessor
{
public TaskResult ProcessOrder(Order order, ReminderTask followUp)
{
if (followUp.IsOverdue) return TaskResult.Blocked;
order.Total = order.Total > 100 ? order.Total - 10 : order.Total;
return TaskResult.Completed;
}
}
```
This method is fully synchronous -- no await, no async keyword, and it calls nothing
asynchronous. `ReminderTask` and `TaskResult` here are this codebase's own domain types (a
follow-up reminder record and an outcome enum) -- unrelated to `System.Threading.Tasks.Task`.
Rate it and list any problems you see. | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-17 Inside a controller action, there's this line:
`_notificationService.SendWelcomeEmailAsync(user);` -- the call is made but its result is never
awaited and never assigned to anything; the method just continues on to its next line
immediately after. SendWelcomeEmailAsync returns a Task. What's the problem with calling it this
way, and what's the fix? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-10 A recurring background timer calls this async method every 30 seconds:
```csharp
public async Task RefreshCacheAsync()
{
try
{
await _cache.ReloadAsync();
}
catch (Exception)
{
}
}
```
If the reload fails, nothing anywhere in the system ever finds out. Given that this is just a
background refresh nobody is directly waiting on, is the empty catch block here acceptable? What
would you change? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-06 I have a C# method that looks up a value from an in-process memory cache. On a cache hit --
which is the overwhelming majority of the many millions of calls per second it handles -- it can
return synchronously right away; only the rare cache-miss path genuinely needs to await anything.
I need one consistent awaitable calling convention for callers either way. Given how hot this
call path is, what return type should this method use instead of a plain Task<T>, and why does
that choice matter here specifically? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-15 Inside one method, the first call is properly awaited
(`var user = await _userService.GetUserAsync(id);`), but a few lines later the same method
reaches for `var prefs = _prefsService.GetPreferencesAsync(id).Result;` for a second, unrelated
call instead of awaiting it. Is it fine that only part of this method blocks synchronously, since
the rest already awaits properly? Explain your answer. | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-12 Here's a method:
```csharp
public async Task<Order> GetOrderAsync(int id)
{
return await _repository.FetchOrderAsync(id);
}
```
All it does is await one call and immediately hand back its result, with no other logic before or
after the await. Is keeping the async/await keywords here the right call, or should this be
restructured -- and if so, how exactly would you rewrite it? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-03 I have a controller action that needs to call three unrelated downstream services and only continue once all three come back:
```csharp
public async Task<Summary> BuildSummaryAsync()
{
var a = await _svcA.FetchAsync();
var b = await _svcB.FetchAsync();
var c = await _svcC.FetchAsync();
return new Summary(a, b, c);
}
```
Is this the right way to structure it? Give me your reasoning and a revised version if it needs to change. | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-13 I'm writing a method that regenerates a large report, and depending on the dataset it can take
anywhere from a few seconds to several minutes. Users need a way to abandon the operation partway
through if they close the report window before it finishes. What should this method's signature
include to support that, and where does that piece typically need to be threaded if the method
calls other async helper methods internally? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-20 We're designing the public surface of a new NuGet package that performs network I/O. For any
operation in this package's public API that does I/O, what asynchronous pattern should its
method signatures follow so consumers get predictable, composable async behavior? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-01 I just wrote this C# method for our service layer:
```csharp
public async void SaveUser(User user)
{
try
{
await _db.SaveAsync(user);
}
catch (Exception ex)
{
}
}
```
Can you review it and give me a bullet list of every problem you see, with a corrected version of the method at the end? | pass→pass | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-02 Doing a PR review for a shared C# library and want a second opinion before I approve it:
```csharp
public Task<string> GetData()
{
var result = httpClient.GetStringAsync(url).Result;
return Task.FromResult(result);
}
```
Walk through what's off with this implementation one issue at a time, explain why each matters, and show me how you'd rewrite it. | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-18 We're building a feature where a user kicks off a multi-minute video-transcoding job from the
UI, then wants to see live progress and be able to cancel it while it runs -- not just fire it
and wait silently for a single final result. At a high level, what implementation pattern would
you reach for to structure an operation like this? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-24 Here's a WinForms button-click handler wired up in the designer file:
```csharp
private async void SaveButton_Click(object sender, EventArgs e)
{
await _repository.SaveAsync(_currentRecord);
}
```
Is the `async void` signature here something I need to fix before merging this? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-05 We have a scheduled background job trigger method invoked only by our own in-process job
scheduler code -- never by a UI framework or any event-subscription mechanism. It's currently a
bare fire-and-forget method with no return value, and I want to change it so callers can detect
failure and await its completion. What should its new return type be, and does the fact that it
currently has no return value at all make it an acceptable exception to leave as-is? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-14 A teammate can't make a class constructor `async` (constructors can't be awaited), so to run some
required async setup during construction they wrote this inside the constructor body:
`var config = _configService.LoadAsync().GetAwaiter().GetResult();`. Is that an acceptable way to
get the async result synchronously in a constructor, and if not, what's the actual fix? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-04 My team wants a short checklist we can run every new C# pull request against for how we handle async code -- covering things like method naming, what types async methods should return, and error handling. Can you draft that checklist for me, then apply it against this sample controller to show which lines would fail it?
```csharp
public class OrdersController
{
public void ProcessOrder(int id)
{
var order = _repo.GetOrder(id).Result;
order.Process();
}
}
``` | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-11 A method calls a flaky third-party pricing API. I want it to proceed with a fallback price if
that call hasn't completed within 2 seconds, without cancelling the original call outright. Two
tasks are involved: the real pricing call, and a delay task representing the 2-second cutoff.
Which Task-combinator method should I use to detect whichever of the two finishes first, and how
would its result tell me whether to use the real price or the fallback? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
▸case-09 Here's a method:
```csharp
public async Task<PaymentResult> ChargeCardAsync(Card card, decimal amount)
{
var response = await _paymentGateway.SubmitAsync(card, amount);
return new PaymentResult(response.Success, response.TransactionId);
}
```
There is no try/catch anywhere in this method, and the gateway call can throw for a declined card
or a network failure. What's missing here, and how would you restructure the method to address
it? | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |