[pull] main from activepieces:main

brain/knowledge/flows-execution/flows.md

@@ -32,6 +32,7 @@ Flows are the core automation primitive: a versioned directed graph of trigger +
 - List filtering: `folderId` uses the string sentinel `"NULL"` for uncategorized; `folderIds` (array) loads all foldered flows in one request.
 - Builder is Zustand-sliced (flow/run/canvas/step-form/piece-selector state). Canvas supports vertical (default) and horizontal orientations, and PNG export via a hand-rolled clone-and-rasterize pipeline.
 - **`Popover.Trigger asChild` always composes its own open-toggle onto the child's click, even when `open`/`onOpenChange` is externally controlled — a `preventDefault()`-shaped guard is the only thing that stops it.** Radix wires `onClick={composeEventHandlers(props.onClick, context.onOpenToggle)}` on the trigger, and `composeEventHandlers` skips the second handler only if `event.defaultPrevented`. `ApStepCanvasNode` wraps *every* step (trigger and action) in `<PieceSelector openSelectorOnClick={false}>` (`flow-canvas/nodes/step-node/index.tsx`), but that prop only guards the app's own `onClick` — it was `handleStepClick`'s incidental `e.preventDefault()` that actually suppressed Radix's toggle for ordinary steps. PR #14405 ("close trigger piece selector on outside/repeat click") removed that `preventDefault()` and made `pieces-selector/index.tsx`'s `onOpenChange` unconditionally honor `open` for any step id — fixing a real empty-trigger close/repeat-click race, but with nothing scoping the new open-branch to the empty trigger specifically. Regression window: 2026-07-28 (#14405) to 2026-08-11 — any plain click on a *configured* step's body reopened its own piece selector, not just the empty trigger (case 1) or an explicit Replace (case 2, which sets the state directly from the context menu and never touches this trigger). Fix: gate the `onOpenChange` open-branch on `isForEmptyTrigger || openSelectorOnClick` instead of honoring every toggle — Radix's own attempt to open is simply ignored (state doesn't change, so the controlled `open` prop stays false) when neither condition holds. Confirmed both the break and the fix by reproducing the exact `Popover.Root`/`Trigger asChild` wiring against the real installed `radix-ui` package in a throwaway vitest — not just static reading. The general lesson (Radix always attempts the toggle; controlled mode only means *you* decide whether to honor it) applies to every controlled Radix `Trigger` in this codebase, not just this one.
+- **Anything drawn in canvas coordinates must measure the canvas element, never infer its offset from app chrome.** The note and step drag previews are `position: absolute` inside the canvas and used to subtract `#project-sidebar`'s width plus a hardcoded 60px header; when the chat-first rail (#15005) replaced that sidebar the id vanished, the width read 0, and Add note silently stopped working — the preview drew a sidebar-width right of the cursor, so the placing click always missed it. Take the origin from xyflow's `useStore((s) => s.domNode)?.getBoundingClientRect()`. `position: fixed` is no way out: an ancestor carries `will-change: transform`, which makes it the containing block.
 - **A stray DRAFT row makes a published flow look blank.** "Latest version" is resolved by `getFlowVersionOrThrow({ versionId: undefined })`, which is just `ORDER BY created DESC` with no state filter — so any DRAFT created after the LOCKED version *is* what the builder opens. This is why a half-created draft is a user-visible outage, not DB litter: recovering needs the row deleted or a `USE_AS_DRAFT`. Editing a published flow used to commit the empty DRAFT and import the locked content into it as two separate writes, so an import failure (field case: `RangeError: Maximum call stack size exceeded` on deeply nested flows — the recursive `sanitizeObjectForPostgresql` before the save is the prime suspect) left the flow rendering empty forever. GIT-1590 / Pylon #5225; the `RangeError` itself is still open as GIT-1593.
 - **Draft creation is now atomic, in two different ways — know which one you're in.** `createNewDraftIfVersionIsPublished` runs `createEmptyVersion` + the IMPORT_FLOW loop in one `transaction()`, threading the `entityManager` down through `applyOperation` to the `updateLastModified` side effect. The *user's* operation deliberately stays outside that transaction (it would hold Postgres open across `prepareRequest` piece-metadata fetches and non-rollbackable file/webhook side effects) and is instead undone by a compensating `delete` of the freshly created draft. `flowService.create` wraps the flow row + first empty version the same way, so a failure can't leave a zero-version, unopenable flow.
 - **`flowVersionSideEffects.preApplyOperation` writes on the default connection, so it escapes any caller transaction.** `handleSampleDataDeletion` and `handleUpdateTriggerWebhookSimulation` take no `entityManager`; a write they make from inside a `transaction()` survives its rollback. They early-return for `IMPORT_FLOW`/`UPDATE_SAMPLE_DATA_INFO`, so the transactional path above is safe today — but adding an operation type to it silently reintroduces partial commits. `updateLastModified` sits outside that swallow-all catch on purpose: a swallowed statement failure inside a transaction poisons it and resurfaces as a confusing "transaction is aborted" error on the next statement.

packages/pieces/community/hugging-face/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@activepieces/piece-hugging-face",
-  "version": "0.1.8",
+  "version": "0.2.0",
   "main": "./dist/src/index.js",
   "types": "./dist/src/index.d.ts",
   "dependencies": {
@@ -12,11 +12,13 @@
     "@activepieces/core-utils": "workspace:*"
   },
   "devDependencies": {
-    "tslib": "2.6.2"
+    "tslib": "2.6.2",
+    "vitest": "3.2.6"
   },
   "scripts": {
     "build": "tsc -p tsconfig.lib.json && cp package.json dist/",
     "bundle": "node ../../../../dist/packages/cli/src/index.js pieces bundle",
-    "lint": "eslint 'src/**/*.ts'"
+    "lint": "eslint 'src/**/*.ts'",
+    "test": "vitest run"
   }
 }