Webhook mode standard delivers wrong header names

[Fraaankes]

Describe the bug
After setting the env DESTINATIONS_WEBHOOK_MODE=standard i am observing that my webhook destination is receiving the following headers:

x-outpost-topic: order.completed
x-outpost-timestamp: 1769699475
x-outpost-signature: v1,dJtLfWX/Nx7JJ8MXtyucwceTrhzD+qRMHigT0xJ/xsE=
x-outpost-id: 4ba74706-4744-4054-8c6d-0d7fe604b356

Based on the v1 signature, it appears to be hashing according to the standards mode, but the header name prefix is supposed to be webhook- according to the documentation.
Note that I do not have DESTINATIONS_WEBHOOK_HEADER_PREFIX set, and I could probably fix it by setting it myself, but this seems like a bug.

To Reproduce
Steps to reproduce the behavior:

1. Set webhook mode to standard
2. Add a destination
3. Publish an event
4. Observe the header names received

Expected behavior
Received headers matches according too the documentation

Prefix for metadata headers added to webhook requests. Defaults to 'x-outpost-' in 'default' mode and 'webhook-' in 'standard' mode.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Tracing through the code a bit, I believe the problem comes from here https://github.com/hookdeck/outpost/blob/main/internal/destregistry/providers/default.go#L59 where the global default value, is overriding the standard default value from here https://github.com/hookdeck/outpost/blob/main/internal/destregistry/providers/destwebhookstandard/destwebhookstandard.go#L123 when the opts are applied

[alexluong]

Hi @Fraaankes, thank you so much for sharing this report. From an initial exploration, I'm seeing the same thing you're seeing, so confirming this is an actual bug. Appreciate you doing the work tracing through the code as well, very helpful!

Are you running Outpost in production? If so, I recommend you set the DESTINATIONS_WEBHOOK_HEADER_PREFIX config yourself for now. We're doing some final changes before v1.0 and about to release a few breaking changes, so I don't think it's super straightforward for us to cut a minor fix. So if you can make do with the workaround, that would probably the easiest way.

I'll make sure this fix will be in v0.13.0 moving forward. Thanks!

[Fraaankes]

Thank you for the quick triage @alexluong - And thank you for your efforts in making a solid product, its much appreciated.
Im happy to specify the prefix manually, as this was found in some pre-production testing.

Not to be the bearer of bad news, but unfortunately it doesn't seem like I would be able to absorb an update just yet, as im hitting the same issue as this one #615 using Azure Managed Redis for all versions above 0.10.0 with the same stack trace 😔

{"level":"error","ts":1769712171.8655417,"caller":"services/retrymq_worker.go:37","msg":"retry scheduler monitor error","error":"mismatched message response type: got <nil>, value: <nil>","stacktrace":"github.com/hookdeck/outpost/internal/services.(*RetryMQWorker).Run\n\t/home/runner/work/outpost/outpost/internal/services/retrymq_worker.go:37\ngithub.com/hookdeck/outpost/internal/worker.(*WorkerSupervisor).Run.func1\n\t/home/runner/work/outpost/outpost/internal/worker/supervisor.go:107"}

{"level":"error","ts":1769712171.8656,"caller":"worker/supervisor.go:108","msg":"worker failed","worker":"retrymq-consumer","error":"mismatched message response type: got <nil>, value: <nil>","stacktrace":"github.com/hookdeck/outpost/internal/worker.(*WorkerSupervisor).Run.func1\n\t/home/runner/work/outpost/outpost/internal/worker/supervisor.go:108"}

[alexluong]

Have you tried v0.12.0 by chance? It should have been fixed there. I tested it myself with a real Azure Managed Redis. If you're still running into this issue with v0.12.0, pleaser do let me know, I'd love to look into it further.

Which Azure Managed Redis tier are you using, if you don't mind me asking? Just want to make sure I can test with the right version.

[Fraaankes]

Yes, I am unfortunately still seeing the issue on v0.12.0, where the api service is failing to start with the above. The log and delivery service appears to be booting up fine.

Which Azure Managed Redis tier are you using, if you don't mind me asking?

Im seeing the issue on a Redis instance on "Balanced: vCPUs: 2, Cache 0.5 GB, SKU B0" running Redis version 7.4