mirror of
https://github.com/supabase/supabase.git
synced 2026-10-09 11:25:06 +03:00
Jordi EnricandClaude Opus 4.6
25f1648e3a
## Problem Individual edge function logs are broken on the OTEL logs path. The logs chart for a single function filters by the `metadata.function_id` override key passed from the function logs page. On the OTEL path this key has no filter template, so it falls through to the unknown-clause resolver and is emitted verbatim as `log_attributes['metadata.function_id']`. OTEL drops the `metadata` root, so the live attribute key is just `function_id`. The filter matched nothing and the chart came back empty. Generated before: ```sql WHERE source = 'function_logs' AND (log_attributes['metadata.function_id'] = '...') ``` ## Fix Strip a leading `metadata.` prefix in the OTEL unknown-clause resolver (`resolveUnknownOtelClause`). The same BigQuery-style override key now resolves to `log_attributes['function_id']`, matching the working invocations query. This is the documented OTEL convention (the `metadata` root is always dropped), so it also covers any other `metadata.*` override keys. Generated after: ```sql WHERE source = 'function_logs' AND (log_attributes['function_id'] = '...') ``` ## How to test - Enable the OTEL logs path and open an edge function's Logs tab for a project with recent invocations. - Confirm the logs chart renders ok/warning/error buckets instead of an empty chart. - Run the unit tests: `pnpm test:studio` (or target `Logs.utils.otel.test.ts`). - Expected result: the new test "drops the metadata root from an override key for function logs" passes, asserting the generated SQL uses `log_attributes['function_id']`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed OTEL filter handling so keys that include the `metadata.` prefix are translated correctly for log searches. * Filters like `metadata.function_id` now generate the expected log-attribute predicates, improving Function logs matching. * **Tests** * Added/updated inline snapshot coverage to verify SQL generation for metadata-based log filter overrides in both chart and preview queries. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.6 <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