twenty

vynte-infra/twenty

Fork 0

...

Author	SHA1	Message	Date
Sonarly Claude Code	57b2cd3f8f	isRecordMatchingFilter throws on stale filter referencing deleted custom field https://sonarly.com/issue/7898?type=bug When a custom field is deleted from the schema, stale Apollo cache entries still contain filters referencing that field. SSE create events trigger optimistic cache updates that walk these stale queries, causing isRecordMatchingFilter to throw because the filter key no longer maps to any field in the metadata.	2026-03-02 17:40:00 +00:00
Sonarly Claude Code	02491571d7	Stale v1.17.0 frontend cache queries removed 'builtHandlerPath' GraphQL field https://sonarly.com/issue/4132?type=bug A breaking GraphQL schema change in PR #17861 removed `builtHandlerPath` from the `LogicFunction` type without backward compatibility, causing stale-cached v1.17.0 frontend bundles to fail against v1.18.x servers. Fix: ## Root Cause Classification: Category D — Schema Mismatch (Breaking API Change) The fix re-adds `builtHandlerPath` to `LogicFunctionDTO` as a deprecated, nullable optional field to restore backward compatibility with v1.17.0 clients that still query it. ### What was changed ```typescript file=packages/twenty-server/src/engine/metadata-modules/logic-function/dtos/logic-function.dto.ts lines=67-70 @IsString() @IsOptional() @Field({ nullable: true, deprecationReason: 'Use sourceHandlerPath instead' }) builtHandlerPath?: string; ``` This block is inserted between `sourceHandlerPath` and `handlerName`. ### Why this fixes the problem - v1.17.0 clients include `builtHandlerPath` in their `LogicFunctionFields` fragment. Before the fix, the v1.18.x server rejected those queries with a GraphQL validation error (`Cannot query field "builtHandlerPath"`), breaking authentication and all downstream flows for users with stale cached bundles. - After the fix, the field exists in the schema again (marked deprecated and nullable), so the server accepts the query and returns `null` for `builtHandlerPath`. The v1.17.0 client code ignores a `null` value gracefully. - The field was never removed from the database entity (`logic-function.entity.ts` line 44 still has `builtHandlerPath: string`), so the resolver can also return the actual stored value when present — no migration is needed. - The `deprecationReason` signals to current clients and tooling that the field should no longer be used, paving the way for a clean removal in a future major version after all clients have updated.	2026-03-02 17:33:31 +00:00

Author

SHA1

Message

Date

Sonarly Claude Code

57b2cd3f8f

isRecordMatchingFilter throws on stale filter referencing deleted custom field

https://sonarly.com/issue/7898?type=bug

When a custom field is deleted from the schema, stale Apollo cache entries still contain filters referencing that field. SSE create events trigger optimistic cache updates that walk these stale queries, causing isRecordMatchingFilter to throw because the filter key no longer maps to any field in the metadata.

2026-03-02 17:40:00 +00:00

Sonarly Claude Code

02491571d7

Stale v1.17.0 frontend cache queries removed 'builtHandlerPath' GraphQL field

https://sonarly.com/issue/4132?type=bug

A breaking GraphQL schema change in PR #17861 removed `builtHandlerPath` from the `LogicFunction` type without backward compatibility, causing stale-cached v1.17.0 frontend bundles to fail against v1.18.x servers.

Fix: ## Root Cause Classification: Category D — Schema Mismatch (Breaking API Change)

The fix re-adds `builtHandlerPath` to `LogicFunctionDTO` as a **deprecated, nullable optional field** to restore backward compatibility with v1.17.0 clients that still query it.

### What was changed

```typescript file=packages/twenty-server/src/engine/metadata-modules/logic-function/dtos/logic-function.dto.ts lines=67-70
  @IsString()
  @IsOptional()
  @Field({ nullable: true, deprecationReason: 'Use sourceHandlerPath instead' })
  builtHandlerPath?: string;
```

This block is inserted between `sourceHandlerPath` and `handlerName`.

### Why this fixes the problem

- **v1.17.0 clients** include `builtHandlerPath` in their `LogicFunctionFields` fragment. Before the fix, the v1.18.x server rejected those queries with a GraphQL validation error (`Cannot query field "builtHandlerPath"`), breaking authentication and all downstream flows for users with stale cached bundles.
- After the fix, the field exists in the schema again (marked deprecated and nullable), so the server accepts the query and returns `null` for `builtHandlerPath`. The v1.17.0 client code ignores a `null` value gracefully.
- The field was **never removed from the database entity** (`logic-function.entity.ts` line 44 still has `builtHandlerPath: string`), so the resolver can also return the actual stored value when present — no migration is needed.
- The `deprecationReason` signals to current clients and tooling that the field should no longer be used, paving the way for a clean removal in a future major version after all clients have updated.

2026-03-02 17:33:31 +00:00

Compare commits

Diff Content Not Available