feat: WAIT_FOR_WEBHOOK system task — full implementation (epic #888)

[nthmost-orkes]

Summary

Implements the complete `WAIT_FOR_WEBHOOK` system task for Conductor OSS (epic #888).

Originally planned as 6 separate PRs, consolidated into a single branch since the pieces are not independently functional. A precision pass and adversarial code review were done after the initial implementation, folded in here.

• Task foundation — `TaskType.WAIT_FOR_WEBHOOK`, `WaitForWebhookTaskMapper`, `WaitForWebhookTask` (start/execute/cancel), `WebhookTaskDAO` interface + `InMemoryWebhookTaskDAO`
• Webhook config CRUD — `WebhookConfig` model (ported from Orkes, no orgId), `WebhookConfigDAO` interface + `InMemoryWebhookConfigDAO`, `WebhookConfigService`, `WebhooksConfigResource` (`/api/metadata/webhook`)
• Hash routing — `WebhookHashingService` with two-mode hash computation; hash format identical to Orkes Enterprise
• Verification — `WebhookVerifier` interface, `HeaderBasedVerifier`; extensible via Spring beans
• Inbound endpoint — `IncomingWebhookService` (synchronous, no queue), `IncomingWebhookResource` (`POST /webhook/{id}`, `GET /webhook/{id}`)
• `workflowsToStart` — starts new workflow instances on inbound events
• Redis persistence — `RedisWebhookTaskDAO` + `RedisWebhookConfigDAO` for multi-node deployments
• Tests — 15 unit tests

Orkes Enterprise convergence

Designed as a drop-in replacement for the Orkes Enterprise `WAIT_FOR_WEBHOOK` implementation. The `WebhookConfig`, `WebhookTaskDAO`, and `WebhookConfigDAO` interfaces live in `conductor-common` so Orkes can depend on them without pulling in the full `webhook-task` module.

Verified identical to Orkes Enterprise:

• Hash format `workflowName;version;taskRefName;sortedValues` and delimiter `;`
• Sort order (TreeSet on JSONPath keys), JSONArray handling, wildcard detection (`$` prefix)
• DO_WHILE `__N` suffix stripping at task-registration time
• Matcher index key format — identical to `PostgresWebhookDAO.createMatchers()`
• `urlVerified` and `secretValue` preservation on update
• Secret masking (`"***"`) on `getWebhook(id)` and `getAllWebhooks()`
• DAO interfaces have no orgId params — isolation is the implementation's concern
• `orgContextProvider.applyContext(id)` called before any DAO access
• Task output: payload keys spread directly into `outputData` via `putAll()`
• DAO put happens before `setStatus(IN_PROGRESS)` so a DAO failure leaves task status unchanged
• `isAsync()` returns `false`
• Null matcher criteria guarded with explicit skip
• `GET /webhook/{id}`: null ping response now dispatches inline (GET events delivered as query parameters are routed to waiting tasks and `workflowsToStart`)
• `POST /webhook/{id}`: config-not-found returns HTTP 200 (empty body) to prevent provider retry storms

What the Orkes adapter layer needs to supply (see `orkes-io/orkes-conductor#3535`):

1. `OrkesWebhookOrgContextProvider implements WebhookOrgContextProvider`
2. `OrkesRedisWebhookTaskDAO implements WebhookTaskDAO`
3. `OrkesPostgresWebhookConfigDAO implements WebhookConfigDAO`

Correctness fixes (adversarial review)

1. GET ping verification gap — `handlePing` null branch now calls `verifier.verify()` before dispatching; previously unauthenticated GET requests could trigger dispatch.
2. Transaction ordering — removed redundant `webhookTaskDAO.remove()` in `completeTask`; `popAll` already removed the task ID, the stale remove masked `updateTask` failures.
3. Early verifier validation — `WebhooksConfigResource` rejects configs at creation time if no verifier implementation is registered for the type (e.g. STRIPE, TWITTER).
4. Payload key collision warning — `parsePayload` logs WARN when a query parameter overwrites a body field of the same name.
5. Redis `popAll` atomicity — `RedisWebhookTaskDAO` overrides `popAll` with SMEMBERS+DEL, narrowing the race window vs. the default SMEMBERS + N×SREM.

Known issues — deferred (documented in #888)

Yellow: Hash normalization asymmetry

Registration hash appends expected value (e.g. `"PENDING"`); inbound hash appends extracted value (e.g. `"pending"`). Tasks with case-differing match values silently never complete. Fix requires coordinated OSS + Orkes deploy with a migration window for in-flight tasks.

Red: Hash delimiter collision

Routing key uses unescaped `;` as delimiter. Workflow names or task ref names containing `;` produce ambiguous hashes. Fix requires data migration of all `WEBHOOK_TASKS.` keys + coordinated Orkes deploy. Low probability in practice.

Intentional differences from Orkes Enterprise

Synchronous vs async processing

OSS completes matching tasks inline within the HTTP request. Orkes uses `_webhook_queue` + `WebhookWorker`. OSS approach is correct for single-node deployments; use `RedisWebhookTaskDAO` for multi-node.

`POST /webhook/{id}` — body is optional

OSS defaults to `"{}"` when body is absent. Orkes requires a body. More permissive intentionally — some providers (Stripe, GitHub) send POST pings with no body.

Test plan

• `./gradlew :conductor-webhook-task:test` — 15 unit tests pass
• `./gradlew :conductor-redis-persistence:compileJava` — compiles cleanly
• Create a webhook config via `POST /api/metadata/webhook`
• Define a workflow with a `WAIT_FOR_WEBHOOK` task and `matches` input
• Start workflow — verify task parks `IN_PROGRESS`
• `POST /webhook/{id}` with matching payload — verify task completes and workflow advances
• `POST /webhook/{id}` with non-matching payload — verify no tasks complete
• Test `workflowsToStart` — verify new workflow instances start on event
• Test `HEADER_BASED` verifier — verify bad secret returns 400

🤖 Generated with Claude Code