mirror of
https://github.com/supabase/supabase.git
synced 2026-10-07 18:35:07 +03:00
Jordi EnricandClaude Opus 4.8
34163fc0ca
## Problem Webhook log drains (project and org/audit) deliver requests with a malformed, duplicated `Content-Type: application/jsonapplication/json` header. On at least some receivers this breaks body parsing, so the delivered body appears empty even though it is present (confirmed with gzip both on and off). Root cause: the create form seeds a default `Content-Type: application/json` header for webhook drains, and the logflare webhook adaptor's `Tesla.Middleware.JSON` also sets `content-type: application/json` when it encodes the body. Both are sent, and the receiver concatenates the two same-named headers. ## Fix Stop seeding `Content-Type` in the webhook default headers (`getDefaultHeadersByType`). The delivery side already sets it, so a single clean header is sent. OTLP keeps its `application/x-protobuf` default because the OTLP delivery path uses `json: false` and does not set a content type itself. Updated the form tests that assumed the seeded header (the added-header row is now index 0 instead of 1, and the duplicate-header test now adds two explicit rows). ## How to test - Create a webhook (Custom Endpoint) audit log drain pointing at a request bin. - Trigger an audit event and inspect the delivered request: `Content-Type` should be a single `application/json`, and the JSON body should be visible. ## Note This fixes the common case (the seeded default). A user who manually adds a `Content-Type` header to a webhook drain would still hit the duplication; the robust cross-team fix would be for the logflare webhook adaptor to drop an incoming `content-type` before its JSON middleware sets one. Flagging for the logs team. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Log Drain header handling corrected: webhook drains no longer add a default Content-Type; other drain types retain their appropriate defaults. Empty header rows are no longer submitted. * **Tests** * Updated tests to match new header indexing, validation behavior, and submission expectations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Writing components
Where to create your components
- For components that declare the general structure and layout of a page:
/components/layouts/xxx
- For components that are tightly coupled to a specific interface:
/components/interfaces/xxx
- For components that are meant to be reusable across multiple pages:
/components/ui/xxx
- Note: We're gradually moving files out of the
to-be-cleanedfolder into the respective folders as we refactor
Component structure
- If a component has constants and utility methods that are tightly coupled to itself, keep them close to the component and enclose them in a folder with an
index.tsxas an entry point - Otherwise it can just be a file on its own
- For example:
-
components/ui - SampleComponentA - SampleComponentA.tsx - SampleComponentA.constants.ts - SampleComponentA.utils.ts - SampleComponentA.types.ts - index.ts - SampleComponentB.tsx
-
Template for building components
// Declare the prop types of your component
interface ComponentAProps {
sampleProp: string
}
// Name your component accordingly
const ComponentA = ({ sampleProp }: ComponentAProps) => {
return <div>ComponentA: {sampleProp}</div>
}
export default ComponentA