Api: Add background task queue#78
Conversation
There was a problem hiding this comment.
Pull request overview
Adds the initial API-side plumbing for an in-process background task queue that can run queued work items through a hosted service with per-item DI scopes.
Changes:
- Introduces
IBackgroundTaskQueueand aChannel-backed implementation. - Adds
QueuedHostedServiceto drain queued work items and isolate each item in a DI scope. - Registers the queue/hosted service in
Program.csand adds unit tests for execution, scoped resolution, and failure isolation.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/Ignis.Api/Program.cs |
Registers the background task queue and hosted drainer. |
src/Ignis.Api/Services/BackgroundTasks/IBackgroundTaskQueue.cs |
Defines the queue contract for producers and the hosted consumer. |
src/Ignis.Api/Services/BackgroundTasks/BackgroundTaskQueue.cs |
Implements the queue with an unbounded single-reader channel. |
src/Ignis.Api/Services/BackgroundTasks/QueuedHostedService.cs |
Runs queued delegates one at a time inside scoped service providers. |
tests/Ignis.Api.Tests/BackgroundTaskQueueTests.cs |
Adds coverage for queued execution, scoped service resolution, and resilience after failures. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
losolio
force-pushed
the
feature/background-task-queue
branch
from
bdbaa51 to
462e5e4
Compare
losolio
force-pushed
the
feature/background-task-queue
branch
from
462e5e4 to
d315a0e
Compare
| /// its own DI scope so scoped services resolve outside the request. | ||
| /// </summary> | ||
| public sealed class QueuedHostedService( | ||
| BackgroundTaskQueue queue, |
There was a problem hiding this comment.
Not a fan of primary constructors, it messes up naming conventions for member variables. Just wasted time looking for the variable queue which is actually a member variable.
There was a problem hiding this comment.
Thanks. I see your point. Our editorconfig actually states that we prefer primary ctors. I have changed to traditional constructors now, and suggest that we clean up other services with the same pattern, and change .editorconfig.
| // Async scope so IAsyncDisposable scoped services dispose properly. | ||
| await using var scope = scopeFactory.CreateAsyncScope(); | ||
| // CT.None: don't abort in-progress imports on shutdown. | ||
| await workItem(scope.ServiceProvider, CancellationToken.None).ConfigureAwait(false); |
There was a problem hiding this comment.
How long-running is a workItem? Would a workItem be the whole import operation, or just a tiny chunk of it? If the former, I think maybe a hosted service might not be the right choice, but that is something we can decide on in the future, not now, just making this comment to make a mental note for the both of us.
There was a problem hiding this comment.
Yes, my thought was that the complete import would be one workitem, I guess it will take a few minutes. I agree that this has some drawbacks, however it will get us started on imports in an upcoming PR, but agree on the mental note on this.
Introduces IBackgroundTaskQueue. No consumers wired up in this slice; the $archive-import PR will be the first user.
losolio
force-pushed
the
feature/background-task-queue
branch
from
d315a0e to
4014b46
Compare
Plumbing a new IBackgroundTaskQueue. No consumers wired up in this slice; the $archive-import PR will be the first user.