feat(kanban): board webhooks — registration + HMAC outbound delivery#44
Merged
Conversation
Register webhooks on the DB board and deliver kanban events to external URLs, signed with HMAC-SHA256. Implements D2 (next-features-design.md §3). - migration 0017_kanban_webhooks: kanban_webhooks (url, secret, event filter, board scope) + kanban_webhook_deliveries (queue + retry ledger). Coexists with B1's 0016. - handlers/kanban/webhook.rs: list / create / delete (owner-admin only). Create returns the plaintext secret ONCE (then a mask). HTTPS-only + SSRF guard (rejects loopback/private hosts). 20-per-workspace cap. `enqueue_event` queues a delivery for every enabled, subscribed webhook (board-scoped or all-boards). - card.rs: enqueue on create / move / archive (the key lifecycle events). - tasks/webhook_delivery.rs: worker that picks due deliveries, signs the JSON body (X-JType-Signature: sha256=…), POSTs via reqwest, and records the outcome with exponential backoff (dead after max_attempts). Spawned from run_from_env. - hmac crate; routes; module registration. - api.ts + KanbanWebhook(Created) types; Kanban.tsx Webhooks dialog (list / create with event + scope pickers / one-time secret reveal / delete). - tests: webhook_crud_and_enqueue (integration, MySQL) + HMAC known-vector unit test + hex_encode. Verified: cargo check + 39 kanban_tests pass against MySQL (create / secret-once / non-https reject / list / enqueue-on-card-create / delete + the 0017 migration); HMAC signing matches a known RFC-style vector; root + web tsc clean. Notes: migration 0017 (B1 takes 0016). Follow-ups: patch / rotate-secret / test / deliveries-history endpoints + UI; enqueue at patch/restore/delete sites; DNS- rebind hardening; realtime delivery-status events. The worker's live HTTP POST is covered by code + the HMAC unit test (an end-to-end POST needs a receiver). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 22 minutes and 18 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThis PR implements a complete Kanban webhook system: a new DB migration adds ChangesKanban Webhook System
Sequence Diagram(s)sequenceDiagram
rect rgba(135, 206, 235, 0.5)
Note over User,Frontend: Webhook Management (Frontend)
User->>Frontend: Click Webhooks (BoltIcon)
Frontend->>api.kanban.listWebhooks: GET /kanban/webhooks
api.kanban.listWebhooks-->>Frontend: KanbanWebhook[]
User->>Frontend: Submit create form (name, URL, events, scope)
Frontend->>api.kanban.createWebhook: POST /kanban/webhooks
end
rect rgba(144, 238, 144, 0.5)
Note over create_webhook,MySQL: Backend Create & Enqueue
create_webhook->>create_webhook: validate_target_url (HTTPS, SSRF)
create_webhook->>MySQL: INSERT kanban_webhooks
create_webhook-->>Frontend: KanbanWebhookCreated (plaintext secret)
Note over card.rs,MySQL: Card operation triggers enqueue
card.rs->>enqueue_event: card created/moved/archived
enqueue_event->>MySQL: INSERT kanban_webhook_deliveries
end
rect rgba(255, 200, 100, 0.5)
Note over webhook_delivery,TargetURL: Background Delivery Worker
webhook_delivery->>MySQL: SELECT due deliveries
webhook_delivery->>webhook_delivery: HMAC-SHA256 sign payload
webhook_delivery->>TargetURL: POST JSON with signature headers
alt 2xx
webhook_delivery->>MySQL: UPDATE status=succeeded
else error
webhook_delivery->>MySQL: UPDATE status=failed/dead, schedule backoff
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
services/jtype-web/migrations/0017_kanban_webhooks.up.sql (1)
39-39: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winIndex shape misses the dequeue ordering column.
Line 39 indexes
(status, next_retry_at), but the worker dequeues withORDER BY created_at ASC LIMIT ...; this can force extra sorting as the queue grows. Includecreated_atin the same index for cheaper due-item polling.Proposed migration tweak
- KEY idx_deliveries_due (status, next_retry_at), + KEY idx_deliveries_due (status, next_retry_at, created_at),🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@services/jtype-web/migrations/0017_kanban_webhooks.up.sql` at line 39, The index idx_deliveries_due on line 39 is defined as KEY idx_deliveries_due (status, next_retry_at), but the worker dequeues records using ORDER BY created_at ASC, which means the database cannot use the index for the ordering operation and must perform additional sorting. Modify the index definition to include created_at as the third column in the index to align with the dequeue ordering, changing it to KEY idx_deliveries_due (status, next_retry_at, created_at) so the index can efficiently support both the filter and the sort operation during queue polling.services/jtype-web/tests/kanban_tests.rs (1)
1631-1636: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winAssert the cascade-delete side effect explicitly.
The test claims cascade removal of deliveries, but currently only checks
204. Add a post-delete DB assertion so FK cascade regressions are caught.Proposed test addition
let (status, _) = common::req( app, "DELETE", &format!("/api/v1/workspaces/{ws_id}/kanban/webhooks/{wh_id}"), Some(&token), None, ).await; assert_eq!(status, StatusCode::NO_CONTENT); + + let remaining: i64 = sqlx::query_scalar( + "SELECT COUNT(*) FROM kanban_webhook_deliveries WHERE webhook_id = ?" + ) + .bind(&wh_id) + .fetch_one(&pool) + .await + .unwrap(); + assert_eq!(remaining, 0, "deliveries should be removed by ON DELETE CASCADE");🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@services/jtype-web/tests/kanban_tests.rs` around lines 1631 - 1636, The test for webhook deletion only verifies the HTTP status code (204) but does not assert that the cascade delete actually removed the associated deliveries from the database. After the assert_eq call that checks the status code, add a database query to verify that all deliveries associated with the deleted webhook (identified by wh_id) have been removed. This ensures that FK cascade constraints are working correctly and will catch any regressions in the cascade delete behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@services/jtype-web/src/handlers/kanban/card.rs`:
- Around line 277-285: The webhook event enqueue via the enqueue_event function
occurs after the card mutation is committed, creating a non-atomic operation.
Wrap both the card update operation and the enqueue_event call within the same
database transaction so they commit together atomically. Apply this same
transactional pattern to all three locations where this issue occurs (the card
update, move, and archive paths) to ensure that if either the state change or
event enqueue fails, both are rolled back together.
In `@services/jtype-web/src/handlers/kanban/webhook.rs`:
- Around line 167-190: The webhook creation has a race condition where the COUNT
check on kanban_webhooks and the subsequent INSERT are not atomic. Two
concurrent requests can both pass the count validation and exceed the
MAX_WEBHOOKS_PER_WORKSPACE limit. Wrap both the sqlx::query_scalar count check
and the sqlx::query INSERT operation in a transaction using state.pool.begin()
to ensure atomicity, so that the count validation and insertion happen as a
single indivisible operation.
- Around line 99-113: The SSRF filter in the webhook handler uses string
manipulation to extract the host from the URL, which can be bypassed by URLs
with userinfo (like `https://user@127.0.0.1/...`) or IPv6 addresses that don't
match the prefix checks. Replace the manual string-splitting approach starting
with `let host = lower["https://".len()..]...split...next()` with proper URL
parsing (use a Rust URL parsing library) to extract the authority/host
component. Then replace the prefix-based blocked checks with proper host and IP
address classification that validates whether an address is actually internal,
handling both IPv4 (including proper CIDR ranges like 172.16.0.0/12) and IPv6
formats using dedicated IP parsing functions or libraries instead of string
prefix matching.
In `@services/jtype-web/src/tasks/webhook_delivery.rs`:
- Around line 54-67: The webhook delivery selection in the sqlx::query that
fetches rows from kanban_webhook_deliveries with status IN ('pending', 'failed')
lacks atomic ownership claiming, allowing multiple app instances to read and
process the same deliveries concurrently. Replace the current SELECT-only query
with an atomic operation that both selects pending/failed deliveries and claims
ownership (by updating them to a processing/claimed state) in a single database
transaction, preventing duplicate concurrent sends. Then ensure the subsequent
success/failure updates in the send logic only perform terminal-state updates
without re-incrementing attempt count.
- Around line 101-103: The UPDATE query for kanban_webhook_deliveries in the
success path does not reset the last_error field when marking a delivery as
succeeded, which leaves stale error information in the database that can mislead
operators and the UI. Modify the UPDATE query that sets status='succeeded',
attempt_count, last_status_code, and next_retry_at to also include clearing the
last_error field (set it to NULL or empty string) so that successful retries
have clean state with no lingering error messages.
---
Nitpick comments:
In `@services/jtype-web/migrations/0017_kanban_webhooks.up.sql`:
- Line 39: The index idx_deliveries_due on line 39 is defined as KEY
idx_deliveries_due (status, next_retry_at), but the worker dequeues records
using ORDER BY created_at ASC, which means the database cannot use the index for
the ordering operation and must perform additional sorting. Modify the index
definition to include created_at as the third column in the index to align with
the dequeue ordering, changing it to KEY idx_deliveries_due (status,
next_retry_at, created_at) so the index can efficiently support both the filter
and the sort operation during queue polling.
In `@services/jtype-web/tests/kanban_tests.rs`:
- Around line 1631-1636: The test for webhook deletion only verifies the HTTP
status code (204) but does not assert that the cascade delete actually removed
the associated deliveries from the database. After the assert_eq call that
checks the status code, add a database query to verify that all deliveries
associated with the deleted webhook (identified by wh_id) have been removed.
This ensures that FK cascade constraints are working correctly and will catch
any regressions in the cascade delete behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a066210d-2c94-4001-948c-720b8f961cad
⛔ Files ignored due to path filters (1)
services/jtype-web/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (13)
services/jtype-web/Cargo.tomlservices/jtype-web/frontend/src/api.tsservices/jtype-web/frontend/src/pages/Kanban.tsxservices/jtype-web/migrations/0017_kanban_webhooks.down.sqlservices/jtype-web/migrations/0017_kanban_webhooks.up.sqlservices/jtype-web/src/db/migrations.rsservices/jtype-web/src/handlers/kanban/card.rsservices/jtype-web/src/handlers/kanban/mod.rsservices/jtype-web/src/handlers/kanban/webhook.rsservices/jtype-web/src/lib.rsservices/jtype-web/src/tasks/mod.rsservices/jtype-web/src/tasks/webhook_delivery.rsservices/jtype-web/tests/kanban_tests.rs
Comment on lines
+277
to
+285
| super::webhook::enqueue_event( | ||
| &state.pool, | ||
| &workspace_id, | ||
| &board_id, | ||
| "kanban:card-updated", | ||
| json!({ "event": "kanban:card-updated", "cardId": card_id, "boardId": board_id }), | ||
| ) | ||
| .await; | ||
|
|
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Webhook enqueue is non-atomic with the card mutation commit.
These paths commit the card change first, then enqueue webhook delivery rows. A crash/restart in that window persists the card mutation but drops the webhook event, breaking event consistency.
Suggested direction
- tx.commit().await?;
-
- super::webhook::enqueue_event(&state.pool, ...).await;
+ super::webhook::enqueue_event_tx(&mut tx, ...).await?;
+ tx.commit().await?;Apply the same transactional outbox pattern to create/move/archive so state change and event enqueue succeed or fail together.
Also applies to: 733-741, 874-882
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/jtype-web/src/handlers/kanban/card.rs` around lines 277 - 285, The
webhook event enqueue via the enqueue_event function occurs after the card
mutation is committed, creating a non-atomic operation. Wrap both the card
update operation and the enqueue_event call within the same database transaction
so they commit together atomically. Apply this same transactional pattern to all
three locations where this issue occurs (the card update, move, and archive
paths) to ensure that if either the state change or event enqueue fails, both
are rolled back together.
Comment on lines
+167
to
+190
| let count: i64 = sqlx::query_scalar("SELECT COUNT(*) FROM kanban_webhooks WHERE workspace_id = ?") | ||
| .bind(&workspace_id) | ||
| .fetch_one(&state.pool) | ||
| .await?; | ||
| if count >= MAX_WEBHOOKS_PER_WORKSPACE { | ||
| return Err(AppError::BadRequest("too many webhooks for this workspace".into())); | ||
| } | ||
|
|
||
| let id = Uuid::new_v4().to_string(); | ||
| let secret = format!("{}{}", Uuid::new_v4().simple(), Uuid::new_v4().simple()); | ||
| let events_json = serde_json::to_value(&events).unwrap_or(JsonValue::Array(vec![])); | ||
| sqlx::query( | ||
| "INSERT INTO kanban_webhooks (id, workspace_id, board_id, name, target_url, secret, event_types, created_by_user_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?)", | ||
| ) | ||
| .bind(&id) | ||
| .bind(&workspace_id) | ||
| .bind(&payload.board_id) | ||
| .bind(&name) | ||
| .bind(&target_url) | ||
| .bind(&secret) | ||
| .bind(&events_json) | ||
| .bind(&user.id) | ||
| .execute(&state.pool) | ||
| .await?; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Webhook cap check is non-atomic and can be exceeded concurrently.
Lines 167-190 do COUNT(*) then INSERT outside a lock/transaction boundary. Two concurrent creates can both pass the count and push a workspace over the 20-webhook limit. Enforce this atomically (transactional lock or DB-level invariant).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/jtype-web/src/handlers/kanban/webhook.rs` around lines 167 - 190,
The webhook creation has a race condition where the COUNT check on
kanban_webhooks and the subsequent INSERT are not atomic. Two concurrent
requests can both pass the count validation and exceed the
MAX_WEBHOOKS_PER_WORKSPACE limit. Wrap both the sqlx::query_scalar count check
and the sqlx::query INSERT operation in a transaction using state.pool.begin()
to ensure atomicity, so that the count validation and insertion happen as a
single indivisible operation.
Comment on lines
+54
to
+67
| let rows = sqlx::query( | ||
| r#"SELECT d.id, d.webhook_id, d.event_type, d.payload, d.attempt_count, d.max_attempts, | ||
| w.target_url, w.secret | ||
| FROM kanban_webhook_deliveries d | ||
| JOIN kanban_webhooks w ON w.id = d.webhook_id | ||
| WHERE d.status IN ('pending', 'failed') | ||
| AND (d.next_retry_at IS NULL OR d.next_retry_at <= NOW()) | ||
| ORDER BY d.created_at ASC | ||
| LIMIT ?"#, | ||
| ) | ||
| .bind(BATCH) | ||
| .fetch_all(pool) | ||
| .await?; | ||
|
|
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift
Due deliveries are not atomically claimed before sending.
Multiple app instances can read the same pending/failed rows and POST duplicates concurrently because selection and ownership claim are separate (and claim happens effectively after send). This can trigger duplicate downstream side effects and race attempt/status accounting.
Suggested direction
+ // Claim row ownership before POST (compare-and-set)
+ let claim = sqlx::query(
+ "UPDATE kanban_webhook_deliveries
+ SET attempt_count = attempt_count + 1
+ WHERE id = ?
+ AND attempt_count = ?
+ AND status IN ('pending','failed')
+ AND (next_retry_at IS NULL OR next_retry_at <= NOW())",
+ )
+ .bind(&id)
+ .bind(prev_attempts)
+ .execute(pool)
+ .await?;
+ if claim.rows_affected() == 0 {
+ continue; // another worker claimed it
+ }
+
- let attempt = prev_attempts + 1;
+ let attempt = prev_attempts + 1;Then keep success/failure updates as terminal-state updates only (without re-incrementing attempt count again).
Also applies to: 87-95, 97-132
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/jtype-web/src/tasks/webhook_delivery.rs` around lines 54 - 67, The
webhook delivery selection in the sqlx::query that fetches rows from
kanban_webhook_deliveries with status IN ('pending', 'failed') lacks atomic
ownership claiming, allowing multiple app instances to read and process the same
deliveries concurrently. Replace the current SELECT-only query with an atomic
operation that both selects pending/failed deliveries and claims ownership (by
updating them to a processing/claimed state) in a single database transaction,
preventing duplicate concurrent sends. Then ensure the subsequent
success/failure updates in the send logic only perform terminal-state updates
without re-incrementing attempt count.
Comment on lines
+101
to
+103
| sqlx::query( | ||
| "UPDATE kanban_webhook_deliveries SET status='succeeded', attempt_count=?, last_status_code=?, next_retry_at=NULL WHERE id=?", | ||
| ) |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Clear stale error details on successful retry.
A recovered delivery keeps old last_error text because success updates do not reset it, which leaves misleading state for operators/UI.
Proposed fix
- "UPDATE kanban_webhook_deliveries SET status='succeeded', attempt_count=?, last_status_code=?, next_retry_at=NULL WHERE id=?",
+ "UPDATE kanban_webhook_deliveries SET status='succeeded', attempt_count=?, last_status_code=?, last_error=NULL, next_retry_at=NULL WHERE id=?",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| sqlx::query( | |
| "UPDATE kanban_webhook_deliveries SET status='succeeded', attempt_count=?, last_status_code=?, next_retry_at=NULL WHERE id=?", | |
| ) | |
| sqlx::query( | |
| "UPDATE kanban_webhook_deliveries SET status='succeeded', attempt_count=?, last_status_code=?, last_error=NULL, next_retry_at=NULL WHERE id=?", | |
| ) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/jtype-web/src/tasks/webhook_delivery.rs` around lines 101 - 103, The
UPDATE query for kanban_webhook_deliveries in the success path does not reset
the last_error field when marking a delivery as succeeded, which leaves stale
error information in the database that can mislead operators and the UI. Modify
the UPDATE query that sets status='succeeded', attempt_count, last_status_code,
and next_retry_at to also include clearing the last_error field (set it to NULL
or empty string) so that successful retries have clean state with no lingering
error messages.
- validate_target_url now parses the URL with the `url` crate and classifies the host structurally, so `https://user@127.0.0.1/`, private/link-local IPv4, IPv6 loopback/ULA, and `*.internal`/`*.local` can no longer slip past the old prefix check. IP literals are classified via std::net (is_private/is_loopback/…). - delivery worker: reqwest client uses redirect Policy::none() so a 3xx to an internal host can't bypass the create-time validation. - test: webhook_crud_and_enqueue now asserts rejection of userinfo, private-IP, IPv6-loopback and .internal targets. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
# Conflicts: # services/jtype-web/frontend/src/api.ts # services/jtype-web/src/db/migrations.rs # services/jtype-web/src/lib.rs # services/jtype-web/tests/kanban_tests.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Implements D2 — register webhooks on the DB board and deliver kanban events to external URLs, signed with HMAC-SHA256. (next-features-design.md §3)
Changes
0017_kanban_webhooks—kanban_webhooks(url, secret, event filter, board scope) +kanban_webhook_deliveries(queue + retry ledger). Coexists with B1's 0016.handlers/kanban/webhook.rs—list/create/delete(owner-admin only). Create returns the plaintext secret once (then a mask). HTTPS-only + SSRF guard (rejects loopback/private hosts). 20-per-workspace cap.enqueue_eventqueues a delivery for every enabled, subscribed webhook (board-scoped or all-boards).card.rs— enqueue on create / move / archive (the key lifecycle events).tasks/webhook_delivery.rs— worker that picks due deliveries, signs the JSON body (X-JType-Signature: sha256=…), POSTs viareqwest, and records the outcome with exponential backoff (deadaftermax_attempts).hmaccrate; routes; module registration.api.ts+KanbanWebhook(Created)types;Kanban.tsxWebhooks dialog (list / create with event + scope pickers / one-time secret reveal / delete).webhook_crud_and_enqueue(integration, MySQL) + HMAC known-vector unit test +hex_encode.Verification
cargo check+ 39kanban_testspass against MySQL: create / secret-once / non-https reject / list / enqueue-on-card-create / delete + the 0017 migration.hmac_sha256_matches_known_vector).tscclean.Notes / follow-ups
patch/rotate-secret/test/ deliveries-history endpoints + UI; enqueue atpatch/restore/deletesites; DNS-rebind hardening; realtime delivery-status events.🤖 Generated with Claude Code
Summary by CodeRabbit