semi implemented and features implemented save checkpoint

This commit is contained in:
master
2026-02-08 18:00:49 +02:00
parent 04360dff63
commit 1bf6bbf395
20895 changed files with 716795 additions and 64 deletions

View File

@@ -0,0 +1,30 @@
# Durable Submission Queue
## Module
Attestor
## Status
IMPLEMENTED
## Description
Durable Rekor submission queue with backend support, submission responses, and entry event tracking.
## Implementation Details
- **Queue Interface**: `src/Attestor/StellaOps.Attestor/StellaOps.Attestor.Core/Queue/IRekorSubmissionQueue.cs` -- durable queue interface for Rekor submissions.
- **Queue Models**: `RekorQueueItem.cs` -- queue item with payload, status, and retry metadata. `RekorSubmissionStatus.cs` -- status enum (Pending, Processing, Completed, Failed). `QueueDepthSnapshot.cs` -- queue depth metrics.
- **PostgreSQL Queue**: `StellaOps.Attestor.Infrastructure/Queue/PostgresRekorSubmissionQueue.cs` -- PostgreSQL-backed durable queue using SKIP LOCKED for concurrent consumers.
- **Retry Worker**: `Infrastructure/Workers/RekorRetryWorker.cs` -- background worker retrying failed submissions.
- **Queue Options**: `StellaOps.Attestor.Core/Options/RekorQueueOptions.cs` -- queue configuration (batch size, retry interval, max retries).
- **Rekor Submission Response**: `Rekor/RekorSubmissionResponse.cs` -- response model from Rekor API.
- **Entry Events**: `Rekor/RekorEntryEvent.cs` -- events emitted on submission lifecycle changes.
- **Tests**: `StellaOps.Attestor.Tests/RekorSubmissionQueueTests.cs`, `RekorRetryWorkerTests.cs`, `Integration/PostgresRekorSubmissionQueueIntegrationTests.cs`, `__Tests/StellaOps.Attestor.Core.Tests/Rekor/RekorEntryEventTests.cs`
## E2E Test Plan
- [ ] Enqueue 10 items to `PostgresRekorSubmissionQueue` and verify `QueueDepthSnapshot` shows 10 pending
- [ ] Dequeue items using SKIP LOCKED and verify concurrent consumers do not process the same item
- [ ] Process a queue item successfully and verify status changes to `Completed`
- [ ] Simulate a submission failure and verify status changes to `Failed` with retry count incremented
- [ ] Verify `RekorRetryWorker` picks up failed items after the retry interval and reprocesses them
- [ ] Verify items exceeding max retries are not retried further
- [ ] Verify `RekorEntryEvent` is emitted on each status transition
- [ ] Verify queue survives process restart (items persist in PostgreSQL)