test(bruno): sweep the collection against the actual route table

Audited every request (247 .yml files) against the routes the server
actually registers (extracted from internal/router, group prefixes
resolved). Results:

- 44 stale requests: deleted where the endpoint no longer exists
  (universal-progress GET/PUT /api/progress/:id — routes never existed,
  the handlers were deleted in H1; queue stats/clear-failed/process;
  admin profile page; auth/account) and FIXED where the endpoint exists
  under a different path (kobo token-in-path scheme: every
  /api/sync/kobo/<seg> and /api/v1/kobo/<seg> URL now carries
  {{kobo_device_token}}; /sync/* missing their /api prefix; koreader
  /api/v1/koreader/sync/* -> /api/sync/koreader/*; link-book and
  unlinked-books moved to /api/devices/:id/sync/*).
- koreader Sync Highlights/Sync Notes pointed at endpoints that never
  existed with a body shape to match — rewritten against POST
  /api/sync/koreader/bookmarks (the annotations funnel carries
  highlights and notes arrays).
- 9 files the GUI refused to load: 4 had bruno-invalid script type
  "tests" (converted to after-response), 4 were info/type:collection
  doc files with bogus http blocks (converted to folder.yml folder
  docs), 1 had a dead pre-YAML schema and no route (deleted).
- devices/koreader requests now carry request-level bearer auth
  ({{koreader_device_token}}) — they inherited the collection's user-JWT
  bearer, which device endpoints rightly reject — and their bodies
  reference {{media_item_id}} instead of dead placeholder uuids.
- environments: opds_base_url was empty (every OPDS request missed the
  /opds prefix); set to http://localhost:8765/opds and un-doubled the
  prefix in opds/scenarios.

Known limitation, for the handoff: bru CLI cannot execute .yml request
bodies (the collection is GUI OpenCollection format; the CLI runner
reads bodies from .bru files only). A .bru migration is the remaining
bruno work if CLI runs are wanted.
This commit is contained in:
John O'Keefe committed 2026-10-17 11:49:28 -04:00
1 parent 6808c1babb
commit a85bc8af9b
65 files changed
+409 -2127

No files matched your search

-87
View File
@@ -1,87 +0,0 @@
info:
name: Clear Failed Items
type: http
seq: 8
http:
method: DELETE
url: '{{base_url}}/api/queue/clear-failed'
auth: inherit
docs: |-
## Clear Failed Queue Items
Removes all failed queue items from the queue.
**Method:** DELETE
**Endpoint:** /api/queue/clear-failed
**Authentication:** Required (Bearer token)
**Query Parameters:**
- `older_than` (string, optional): ISO 8601 duration - e.g., `7d`, `24h`, `60m`
- `device_id` (string, optional): Only clear items from specific device
- `type` (string, optional): Only clear specific item type
**Request Body:**
Optional filters:
```json
{
"older_than": "7d",
"device_id": "uuid",
"type": "progress"
}
```
**Response:**
- `deleted_count` (integer): Number of items deleted
- `items_cleared` (array): IDs of cleared items
- `retained_count` (integer): Items not matching filters
- `cleared_at` (string): Deletion timestamp
**Status Codes:**
- 200: Items cleared successfully
- 401: Unauthorized
- 400: Invalid filter parameters
**Deletion Behavior:**
- Removes failed items from queue
- Does not affect pending/processing/completed items
- Permanent deletion (cannot be undone)
- Logs deletion for audit trail
- Updates queue statistics
**Safety Features:**
- Default filter prevents clearing recent failures
- Per-device filtering for targeted cleanup
- Type filtering for selective clearing
- Confirmation required for large deletions
**Recommended Usage:**
- **Daily:** Clear failures older than 7 days
- **Weekly:** Clear all failed items
- **Per-device:** After removing problematic device
- **Per-type:** After fixing specific sync issue
**Use Cases:**
- Clean up old failed sync attempts
- Reduce queue database size
- Remove stuck error items
- Prepare for fresh sync attempts
- Clear items for decommissioned devices
- Reset after bug fixes
**Warnings:**
- Cannot be undone
- Failed items cleared permanently
- Consider retrying before clearing
- May hide recurring issues if overused
- Check logs before bulk clearing
**Best Practices:**
- Review error patterns before clearing
- Fix root causes before cleanup
- Use time-based filters to preserve recent failures
- Document reasons for clearing
- Monitor failure rates after cleanup
-83
View File
@@ -1,83 +0,0 @@
info:
name: Get Queue Statistics
type: http
seq: 9
http:
method: GET
url: '{{base_url}}/api/queue/stats'
auth: inherit
docs: |-
## Get Queue Statistics
Retrieves overall queue performance and status metrics.
**Method:** GET
**Endpoint:** /api/queue/stats
**Authentication:** Required (Bearer token)
**Query Parameters:**
None (all stats returned)
**Response:**
- `overview` (object):
- `total_items` (integer): All items in queue
- `pending` (integer): Items awaiting processing
- `processing` (integer): Items currently being processed
- `completed` (integer): Successfully processed items
- `failed` (integer): Failed items
- `by_type` (object):
- `progress` (object): Progress item counts
- `note` (object): Note item counts
- `highlight` (object): Highlight item counts
- `bookmark` (object): Bookmark item counts
- `by_status` (object):
- `pending`: Count by type
- `processing`: Count by type
- `completed`: Count by type
- `failed`: Count by type
- `performance` (object):
- `avg_processing_time_ms` (number): Average processing duration
- `throughput_per_minute` (number): Items processed per minute
- `success_rate` (number): Percentage of successful processing
- `failure_rate` (number): Percentage of failures
- `timing` (object):
- `oldest_pending_age_seconds` (integer): Age of oldest pending item
- `longest_processing_time_ms` (integer): Longest current processing time
- `peak_queue_size_today` (integer): Maximum queue size today
- `devices` (array): Top 5 devices by queue activity
- `device_id` (string): Device UUID
- `device_name` (string): Device name
- `item_count` (integer): Items in queue from this device
- `retention` (object):
- `completed_items_30_days` (integer): Completed items in retention period
- `purge_scheduled_at` (string): Next auto-purge time
- `generated_at` (string): Statistics generation timestamp
**Status Codes:**
- 200: Success
- 401: Unauthorized
**Cache Behavior:**
- Statistics cached for 60 seconds
- Real-time data may vary slightly
- Use `?refresh=true` to bypass cache
**Use Cases:**
- Monitor queue health
- Identify performance bottlenecks
- Track processing capacity
- Alert on failures
- Capacity planning
- SLA monitoring
- Dashboard metrics
**Key Metrics to Watch:**
- **Success Rate:** Should be >95%
- **Avg Processing Time:** Depends on type
- **Oldest Pending:** Should be <5 minutes
- **Failed Items:** Investigate if >5%
- **Throughput:** Baseline for capacity planning
@@ -4,7 +4,7 @@ info:
seq: 2
http:
method: GET
url: '{{base_url}}/queue/items?limit=50&offset=0'
url: '{{base_url}}/api/queue/items?limit=50&offset=0'
auth: inherit
body:
type: none
-74
View File
@@ -1,74 +0,0 @@
info:
name: Process Queue Item
type: http
seq: 7
http:
method: POST
url: '{{base_url}}/api/queue/items/{{queue_item_id}}/process'
auth: inherit
docs: |-
## Process Queue Item
Manually trigger processing of a specific queue item.
**Method:** POST
**Endpoint:** /api/queue/items/:queue_item_id/process
**Authentication:** Required (Bearer token)
**Path Parameters:**
- `queue_item_id` (string): UUID of the queue item to process
**Request Body:**
Empty or optional:
- `priority` (integer, optional): Override processing priority (0-10)
- `force` (boolean, optional): Re-process even if completed
**Response:**
- `id` (string): Queue item UUID
- `status` (string): New status - `processing` or `queued`
- `type` (string): Item type
- `message` (string): Processing initiation message
- `estimated_duration_ms` (integer): Expected processing time
- `started_at` (string): Processing start time
- `previous_status` (string): Status before processing
**Status Codes:**
- 200: Processing started
- 202: Queued for processing
- 401: Unauthorized
- 404: Queue item not found
- 409: Item already being processed
- 422: Invalid item state
**Processing Behavior:**
- Item moves from `pending` to `processing`
- Can override priority for faster processing
- Force re-processing of completed/failed items
- Updates item's `last_attempt` timestamp
- Increments `retry_count` for failed items
- Validates data before processing
- Executes item-specific handlers
**Use Cases:**
- Retry failed sync items
- Expedite high-priority updates
- Re-process completed items (e.g., after fix)
- Debug queue processing
- Manual intervention for stuck items
- Test specific sync operations
**Processing States:**
- `pending` → `processing` → `completed` or `failed`
- Processing can take 1-30 seconds depending on type
- WebSocket notifications sent on completion
- Automatic retry on transient failures
**Notes:**
- Does not guarantee immediate processing
- Queue workers pick up items based on priority
- Multiple manual processes queue sequentially
- Use WebSocket for real-time updates
-38
View File
@@ -1,38 +0,0 @@
info:
name: Bookhoard Sync Queue API
type: collection
seq: 1
http:
method: GET
url: '"http://localhost:8765/api"'
docs: |-
## Bookhoard Sync Queue API
Collection of endpoints for managing the synchronization queue that handles
background processing of sync operations between devices and the server.
**Base URL:** http://localhost:8765/api
**Authentication:** Bearer token required for most endpoints
**Endpoints:**
- Queue item management (create, process, retry, delete)
- Queue statistics and monitoring
- Device-specific queue operations
- Filtering by type (highlights, notes, bookmarks, progress)
- Filtering by status (pending, completed, failed)
- Bulk operations (clear device queue, clear failed items)
**Queue Item Types:**
- `highlight`: Highlight synchronization
- `note`: Note synchronization
- `bookmark`: Bookmark synchronization
- `progress`: Reading progress synchronization
**Queue Status Values:**
- `pending`: Awaiting processing
- `processing`: Currently being processed
- `completed`: Successfully processed
- `failed`: Processing failed (retryable)
- `cancelled`: Item was cancelled
+8
View File
@@ -0,0 +1,8 @@
info:
name: Bookhoard Sync Queue API
type: folder
seq: 1
request:
auth: inherit
docs: "## Bookhoard Sync Queue API\n\n Collection of endpoints for managing the synchronization queue that handles\n background processing of sync operations between devices and the server.\n\n **Base URL:** http://localhost:8765/api\n\n **Authentication:** Bearer token required for most endpoints\n\n **Endpoints:**\n - Queue item management (create, process, retry, delete)\n - Queue statistics and monitoring\n - Device-specific queue operations\n - Filtering by type (highlights, notes, bookmarks, progress)\n - Filtering by status (pending, completed, failed)\n - Bulk operations (clear device queue, clear failed items)\n\n **Queue Item Types:**\n - `highlight`: Highlight synchronization\n - `note`: Note synchronization\n - `bookmark`: Bookmark synchronization\n - `progress`: Reading progress synchronization\n\n **Queue Status Values:**\n - `pending`: Awaiting processing\n - `processing`: Currently being processed\n - `completed`: Successfully processed\n - `failed`:\
\ Processing failed (retryable)\n - `cancelled`: Item was cancelled"
@@ -4,7 +4,7 @@ info:
seq: 3
http:
method: GET
url: '{{base_url}}/queue/items?status=pending'
url: '{{base_url}}/api/queue/items?status=pending'
auth: inherit
body:
type: none