Skip to content

fix: type properties as record on events list schema (untested)#86

Open
kylegrahammatzen wants to merge 1 commit into
useautumn:mainfrom
kylegrahammatzen:fix/events-list-properties-type
Open

fix: type properties as record on events list schema (untested)#86
kylegrahammatzen wants to merge 1 commit into
useautumn:mainfrom
kylegrahammatzen:fix/events-list-properties-type

Conversation

@kylegrahammatzen

@kylegrahammatzen kylegrahammatzen commented Apr 6, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes the SDK events list schema so properties supports arbitrary JSON values.

Related Issues

Fixes an issue where properties was not being returned correctly in the SDK.

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Refactor
  • Other (please describe):

Checklist

  • I have read the CONTRIBUTING.md
  • My code follows the code style of this project
  • I have added tests where applicable
  • I have tested my changes locally
  • I have linked relevant issues
  • I have added screenshots for UI changes (if applicable)

Screenshots (if applicable)

N/A

Additional Context

Changes properties from an empty object schema to a record in the SDK.


Summary by cubic

Fixes the events list schema so properties supports arbitrary JSON and returns correctly in the SDK. Replaces z.object({}) with z.record(z.string(), z.unknown()) to match JSONB storage.

Written for commit 51e86c1. Summary will update on new commits.

Greptile Summary

This PR corrects the Zod schema for EventsListItemSchema.properties, replacing the semantically incorrect z.object({}) with z.record(z.string(), z.unknown()), which properly represents arbitrary JSONB key-value data returned by the events list API.

Key changes:

  • [Bug fix] properties in EventsListItemSchema was typed as z.object({}), which in Zod validates only an empty object and strips or rejects all actual properties at runtime — incorrect for a JSONB column that holds arbitrary data.
  • [Improvements, API changes] The inferred TypeScript type for EventsListItem.properties changes from {} to Record<string, unknown>, now accurately reflecting the data shape returned by the API. Existing consumers (Object.keys() and JSON.stringify() in event-list-viewer.tsx) are fully compatible with this new type.

Note: The PR title explicitly marks this change as "untested" and the author left the "I have tested my changes locally" checklist item unchecked. While the code change is logically correct, it has not been verified against a live environment.

Confidence Score: 4/5

Safe to merge — targeted, correct fix for an incorrect Zod schema type with no breaking consumers

Single-line change is logically correct: z.record(z.string(), z.unknown()) properly represents JSONB data. No existing code is broken by the type change (only usages are Object.keys() and JSON.stringify()). Minor concern is that the author self-flagged the change as untested.

No files require special attention; the change is minimal and isolated to a single schema definition.

Important Files Changed

Filename Overview
package/src/sdk/events/eventTypes.ts Fixes properties schema from restrictive empty object to Record<string, unknown>, correctly representing arbitrary JSONB data

Sequence Diagram

sequenceDiagram
    participant C as Client
    participant SDK as Autumn SDK
    participant API as Autumn API

    C->>SDK: events.list(params)
    SDK->>API: GET /events (paginated)
    API-->>SDK: JSON response with properties (JSONB)
    SDK->>SDK: Parse via EventsListItemSchema
    Note over SDK: properties: z.record(z.string(), z.unknown())<br/>Previously: z.object({}) — stripped all props
    SDK-->>C: EventsListItem[] with full properties
Loading

Reviews (1): Last reviewed commit: "fix: type properties as record on events..." | Re-trigger Greptile

Context used:

  • Context used - When generating the key changes section of the sum... (source)

@vercel

vercel Bot commented Apr 6, 2026

Copy link
Copy Markdown

@kylegrahammatzen is attempting to deploy a commit to the Autumn Team on Vercel.

A member of the Team first needs to authorize it.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 1 file

Confidence score: 5/5

  • Automated review surfaced no issues in the provided summaries.
  • No files require special attention.

@entelligence-ai-pr-reviews

entelligence-ai-pr-reviews Bot commented Apr 6, 2026

Copy link
Copy Markdown

EntelligenceAI PR Summary

Relaxes the properties field validation in EventsListItemSchema to accommodate dynamic JSONB data structures.

  • Changed properties schema from z.object({}) (rigid, empty object) to z.record(z.string(), z.unknown()) (flexible key-value map)
  • Affects EventsListItemSchema in package/src/sdk/events/eventTypes.ts
  • Enables the schema to accept any string-keyed properties with unknown value types, reflecting the JSONB column behavior

Confidence Score: 4/5 - Mostly Safe

Safe to merge — the change in eventTypes.ts correctly relaxes EventsListItemSchema's properties field from z.object({}) to z.record(z.string(), z.unknown()), which accurately reflects the dynamic JSONB nature of event properties and prevents unnecessary validation failures on valid data. The PR is narrow in scope, touching a single schema definition, and the direction of change (more permissive, aligned with actual data shape) is sound. The title flags this as 'untested', which is a minor concern worth noting — ideally a snapshot or unit test covering the schema against a sample event payload would accompany this, but the change itself introduces no logic bugs or regressions.

Key Findings:

  • z.object({}) was effectively rejecting any event with non-empty properties due to Zod's strict object behavior; replacing it with z.record(z.string(), z.unknown()) is the semantically correct fix for a JSONB column that can hold arbitrary key-value pairs.
  • The PR author self-notes it is 'untested', meaning no automated test coverage was added or updated to validate the new schema behavior against real or mocked event payloads — this is a mild gap but not a blocking concern given the simplicity of the change.
  • No other schema fields in EventsListItemSchema are affected, and the change is strictly additive in terms of valid inputs, so no downstream consumers of this schema should break.
Files requiring special attention
  • package/src/sdk/events/eventTypes.ts

@entelligence-ai-pr-reviews

Copy link
Copy Markdown

Walkthrough

This update relaxes the properties field schema in EventsListItemSchema from a strict empty object (z.object({})) to a flexible z.record(z.string(), z.unknown()). This change allows the field to accept arbitrary key-value pairs with string keys and unknown values, better aligning the schema with the underlying JSONB column's dynamic nature.

Changes

File(s) Summary
package/src/sdk/events/eventTypes.ts Updated properties field schema in EventsListItemSchema from z.object({}) to z.record(z.string(), z.unknown()) to support arbitrary key-value pairs.

Sequence Diagram

This diagram shows the interactions between components:

sequenceDiagram
    participant Client
    participant EventsListItemSchema as "EventsListItemSchema (Zod)"
    participant Consumer as "Schema Consumer"

    Client->>EventsListItemSchema: Parse event data
    Note over EventsListItemSchema: Validates fields:<br/>feature_id, customer_id,<br/>value, properties
    alt properties is flexible map (new behavior)
        EventsListItemSchema-->>Client: Accepts any string-keyed properties
        Note over EventsListItemSchema: z.record(z.string(), z.unknown())<br/>allows dynamic JSONB fields
    else properties was empty object (old behavior)
        EventsListItemSchema-->>Client: Rejected unknown property keys
        Note over EventsListItemSchema: z.object({}) blocked<br/>dynamic JSONB fields
    end

    Client->>Consumer: Pass validated EventsListItem
    Note over Consumer: EventsListItem type now includes<br/>properties: Record<string, unknown>
Loading

🔗 Cross-Repository Impact Analysis

Enable automatic detection of breaking changes across your dependent repositories. → Set up now

Learn more about Cross-Repository Analysis

What It Does

  • Automatically identifies repositories that depend on this code
  • Analyzes potential breaking changes across your entire codebase
  • Provides risk assessment before merging to prevent cross-repo issues

How to Enable

  1. Visit Settings → Code Management
  2. Configure repository dependencies
  3. Future PRs will automatically include cross-repo impact analysis!

Benefits

  • 🛡️ Prevent breaking changes across repositories
  • 🔍 Catch integration issues before they reach production
  • 📊 Better visibility into your multi-repo architecture

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant