Uh oh!
There was an error while loading. Please reload this page.
feat: add local image processing workflow canvas - #1
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| }: CreateRecipeInput): Recipe { | ||
| const timestamp = new Date().toISOString() | ||
| return parseRecipe({ |
There was a problem hiding this comment.
🟡 Mediumrecipes/recipe.ts:26
createRecipe calls parseRecipe synchronously, so when renameTemplate is invalid (e.g. empty or too long), it throws from the click handler before persist(...) is ever called. Because the save UI only attaches .catch() to the persist(...) promise, that synchronous throw is unhandled and the workspace shows no validation message — the user clicks save and nothing visible happens. Consider awaiting createRecipe inside the async save flow so its validation error is caught by the same .catch() handler, or validate renameTemplate before calling createRecipe.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/recipes/recipe.ts around line 26:
`createRecipe` calls `parseRecipe` synchronously, so when `renameTemplate` is invalid (e.g. empty or too long), it throws from the click handler before `persist(...)` is ever called. Because the save UI only attaches `.catch()` to the `persist(...)` promise, that synchronous throw is unhandled and the workspace shows no validation message — the user clicks save and nothing visible happens. Consider awaiting `createRecipe` inside the async save flow so its validation error is caught by the same `.catch()` handler, or validate `renameTemplate` before calling `createRecipe`.
| return typeof window !== 'undefined' && 'showDirectoryPicker' in window | ||
| } | ||
| export async function pickFolderImages() { |
There was a problem hiding this comment.
🟡 Mediumimage-input/folder.ts:26
pickFolderImages traverses the entire directory tree and calls handle.getFile() for every file before filtering to images and returning — there is no traversal or file-count limit. Selecting a large folder creates a File object for every file on disk (including non-images), which can stall folder selection and consume excessive memory. Consider passing a maximum file count into collectFiles so it stops walking the tree once enough images are collected.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/image-input/folder.ts around line 26:
`pickFolderImages` traverses the entire directory tree and calls `handle.getFile()` for every file before filtering to images and returning — there is no traversal or file-count limit. Selecting a large folder creates a `File` object for every file on disk (including non-images), which can stall folder selection and consume excessive memory. Consider passing a maximum file count into `collectFiles` so it stops walking the tree once enough images are collected.
| }) | ||
| } | ||
| async function withStore<T>( |
There was a problem hiding this comment.
🟡 Mediumrecipes/local-store.ts:42
withStore resolves when the individual IDBRequest succeeds, not when the surrounding transaction commits. A readwrite transaction can still abort after put/delete succeeds, but saveRecipe, savePreferences, and saveRun will already have observed success — so writes are silently lost and the UI shows "saved locally" even when nothing was stored. The transaction must reach its complete event before resolving; reject on abort or error.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/recipes/local-store.ts around line 42:
`withStore` resolves when the individual `IDBRequest` succeeds, not when the surrounding transaction commits. A `readwrite` transaction can still abort after `put`/`delete` succeeds, but `saveRecipe`, `savePreferences`, and `saveRun` will already have observed success — so writes are silently lost and the UI shows "saved locally" even when nothing was stored. The transaction must reach its `complete` event before resolving; reject on `abort` or `error`.
| const PrivacyContext = createContext<PrivacyContextValue | null>(null) | ||
| export function PrivacyProvider({ children }: { children: ReactNode }) { | ||
| const [preferences, setPreferences] = useState(DEFAULT_PREFERENCES) |
There was a problem hiding this comment.
🟠 Highprivacy/privacy-provider.tsx:17
If a user changes a privacy setting before loadPreferences resolves, the stored value overwrites their newer choice. update calls setPreferences synchronously, but the useEffect callback later calls setPreferences(stored) unconditionally, replacing the user's selection with the stale value from IndexedDB. Consider guarding the load with a ref that tracks whether the user has already modified preferences, and skip applying the stored value in that case.
export function PrivacyProvider({ children }: { children: ReactNode }) {
- const [preferences, setPreferences] = useState(DEFAULT_PREFERENCES)+ const [preferences, setPreferences] = useState(DEFAULT_PREFERENCES)+ const userModifiedRef = useRef(false)🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/privacy/privacy-provider.tsx around line 17:
If a user changes a privacy setting before `loadPreferences` resolves, the stored value overwrites their newer choice. `update` calls `setPreferences` synchronously, but the `useEffect` callback later calls `setPreferences(stored)` unconditionally, replacing the user's selection with the stale value from IndexedDB. Consider guarding the load with a ref that tracks whether the user has already modified preferences, and skip applying the stored value in that case.
| let outputName = `${prefix}${stem}.${extension}` | ||
| let collision = 2 | ||
| while (used.has(outputName.toLocaleLowerCase())) { |
There was a problem hiding this comment.
🟡 Mediumprocessing/output.ts:39
createOutputNames uses toLocaleLowerCase() for collision detection, so in Turkish locales I.png and i.png normalize to different keys (ı and i). Both files keep colliding output names instead of the second getting a -2 suffix, defeating the dedup logic. Use toLowerCase() instead so normalization is locale-independent.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/processing/output.ts around line 39:
`createOutputNames` uses `toLocaleLowerCase()` for collision detection, so in Turkish locales `I.png` and `i.png` normalize to different keys (`ı` and `i`). Both files keep colliding output names instead of the second getting a `-2` suffix, defeating the dedup logic. Use `toLowerCase()` instead so normalization is locale-independent.
| try { | ||
| for (const { file, relativePath } of files.slice(0, MAX_BATCH_FILES)) { | ||
| try { | ||
| const info = inspectImageHeader(await file.arrayBuffer(), file.type) | ||
| if (selectionId !== selectionIdRef.current) return | ||
| valid.push({ | ||
| id: createId(), | ||
| file, | ||
| info, | ||
| progress: 0, | ||
| relativePath, | ||
| status: 'ready', | ||
| }) | ||
| } catch (reason) { | ||
| const message = | ||
| reason instanceof ImageValidationError | ||
| ? reason.message | ||
| : 'The image could not be inspected.' | ||
| rejected.push(`${relativePath}: ${message}`) | ||
| } | ||
| } | ||
| setBatchItems(valid) | ||
| const first = valid[0] |
There was a problem hiding this comment.
🟡 Mediumcanvas/canvas-workbench.tsx:332
In inspectFiles, when a newer file selection supersedes an older one while the older selection's file.arrayBuffer() or inspectImageHeader call is still pending, a validation failure in the older call triggers its catch block which pushes to rejected and then falls through to setBatchItems(valid), setError, and setFailedNodeId — overwriting the newer selection's state with stale data. The selectionId guard is only checked inside the try after successful validation, not in the catch block or before the final setBatchItems/setError calls. Consider rechecking selectionId in the catch block and before committing final state.
- } catch (reason) {- const message =- reason instanceof ImageValidationError- ? reason.message- : 'The image could not be inspected.'- rejected.push(`${relativePath}: ${message}`)- }+ } catch (reason) {+ if (selectionId !== selectionIdRef.current) return+ const message =+ reason instanceof ImageValidationError+ ? reason.message+ : 'The image could not be inspected.'+ rejected.push(`${relativePath}: ${message}`)+ }
}
- setBatchItems(valid)+ if (selectionId !== selectionIdRef.current) return+ setBatchItems(valid)🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/canvas/canvas-workbench.tsx around lines 332-355:
In `inspectFiles`, when a newer file selection supersedes an older one while the older selection's `file.arrayBuffer()` or `inspectImageHeader` call is still pending, a validation failure in the older call triggers its `catch` block which pushes to `rejected` and then falls through to `setBatchItems(valid)`, `setError`, and `setFailedNodeId` — overwriting the newer selection's state with stale data. The `selectionId` guard is only checked inside the `try` after successful validation, not in the `catch` block or before the final `setBatchItems`/`setError` calls. Consider rechecking `selectionId` in the `catch` block and before committing final state.
| recordHistory() | ||
| setNodes((current) => current.filter((node) => !selectedNodeIds.has(node.id))) | ||
| setEdges((current) => | ||
| current.filter( | ||
| (edge) => | ||
| !edge.selected && !selectedNodeIds.has(edge.source) && !selectedNodeIds.has(edge.target), | ||
| ), | ||
| ) | ||
| setGraphIssue('Restore and reconnect missing nodes before running.') | ||
| } |
There was a problem hiding this comment.
🟠 Highcanvas/canvas-workbench.tsx:942
deleteSelected mutates the graph but never invalidates the completed run state, so runState stays complete and the Run button stays hidden even though the modified workflow needs to be rerun. The old result also continues to appear valid for a graph it no longer matches. Connect/reconnect, addMissingNode, applyRecipe, undo, and redo have the same stale-output problem — they all mutate the graph without calling invalidateResult(). Consider calling invalidateResult() (or at least resetting runState) after every graph mutation.
recordHistory()
setNodes((current) => current.filter((node) => !selectedNodeIds.has(node.id)))
setEdges((current) =>
current.filter(
(edge) =>
!edge.selected && !selectedNodeIds.has(edge.source) && !selectedNodeIds.has(edge.target),
),
)
+ invalidateResult()
setGraphIssue('Restore and reconnect missing nodes before running.')🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/canvas/canvas-workbench.tsx around lines 942-951:
`deleteSelected` mutates the graph but never invalidates the completed run state, so `runState` stays `complete` and the Run button stays hidden even though the modified workflow needs to be rerun. The old `result` also continues to appear valid for a graph it no longer matches. Connect/reconnect, `addMissingNode`, `applyRecipe`, `undo`, and `redo` have the same stale-output problem — they all mutate the graph without calling `invalidateResult()`. Consider calling `invalidateResult()` (or at least resetting `runState`) after every graph mutation.
| <Button | ||
| label="Use" | ||
| variant="secondary" | ||
| size="sm" | ||
| onClick={() => onUseTournamentResult(entry.format)} | ||
| /> |
There was a problem hiding this comment.
🟡 Mediumcomparison/image-lab.tsx:83
The Use button on each tournament result is enabled while the tournament is still running, so clicking it mid-run calls onUseTournamentResult, which sets the shared run state to complete and re-enables processing actions while runTournament is still processing later codecs. This causes conflicting progress and run-state updates. The Use buttons in the tournament list should be disabled when isBusy is true.
<Button
label="Use"
variant="secondary"
size="sm"
- onClick={() => onUseTournamentResult(entry.format)}+ isDisabled={isBusy}+ onClick={() => onUseTournamentResult(entry.format)}
/>🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/comparison/image-lab.tsx around lines 83-88:
The `Use` button on each tournament result is enabled while the tournament is still running, so clicking it mid-run calls `onUseTournamentResult`, which sets the shared run state to `complete` and re-enables processing actions while `runTournament` is still processing later codecs. This causes conflicting progress and run-state updates. The `Use` buttons in the tournament list should be disabled when `isBusy` is true.
| } | ||
| export async function writeOutputsToFolder(outputs: OutputFile[]) { | ||
| const picker = (window as FolderPickerWindow).showDirectoryPicker |
There was a problem hiding this comment.
🟠 Highprocessing/output-delivery.ts:27
writeOutputsToFolder extracts window.showDirectoryPicker into a standalone variable and then invokes it without the window receiver, which throws TypeError: Illegal invocation in supporting browsers and prevents every folder-save operation from completing. Call the method directly as window.showDirectoryPicker() or bind it to window before calling.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/features/processing/output-delivery.ts around line 27:
`writeOutputsToFolder` extracts `window.showDirectoryPicker` into a standalone variable and then invokes it without the `window` receiver, which throws `TypeError: Illegal invocation` in supporting browsers and prevents every folder-save operation from completing. Call the method directly as `window.showDirectoryPicker()` or bind it to `window` before calling.
| overflow: hidden; | ||
| } | ||
| .difference-preview__source { |
There was a problem hiding this comment.
🟡 Mediumsrc/styles.css:42
The source image inside .astryx-overlay-scrim is sized to width: 100% of that wrapper, but the wrapper's width is reduced to var(--difference-reveal). At a 50% split the source image is squeezed into a half-width box and scaled by object-fit: contain instead of staying full-size and being clipped — so source pixels no longer align with the result image and the comparison is misleading. The image should retain the full viewport width while only the clipping container's width changes. Consider setting the image to a fixed full-preview width (e.g. matching .difference-preview) rather than 100% of the scrim.
Also found in 1 other location(s)
src/features/comparison/image-comparison.tsx:79
The slider comparison places the source image inside
.astryx-overlay-scrim, while the stylesheet changes that wrapper's width to--difference-revealand gives its imagewidth: 100%. As the slider moves, the source image is resized into the shrinking wrapper rather than remaining full-size and being clipped, so it no longer aligns pixel-for-pixel with the result and the visual difference view is misleading. The source image needs to retain the full comparison viewport width while only its clipping container changes width.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @src/styles.css around line 42:
The source image inside `.astryx-overlay-scrim` is sized to `width: 100%` of that wrapper, but the wrapper's width is reduced to `var(--difference-reveal)`. At a 50% split the source image is squeezed into a half-width box and scaled by `object-fit: contain` instead of staying full-size and being clipped — so source pixels no longer align with the result image and the comparison is misleading. The image should retain the full viewport width while only the clipping container's width changes. Consider setting the image to a fixed full-preview width (e.g. matching `.difference-preview`) rather than `100%` of the scrim.
Also found in 1 other location(s):
- src/features/comparison/image-comparison.tsx:79 -- The slider comparison places the source image inside `.astryx-overlay-scrim`, while the stylesheet changes that wrapper's width to `--difference-reveal` and gives its image `width: 100%`. As the slider moves, the source image is resized into the shrinking wrapper rather than remaining full-size and being clipped, so it no longer aligns pixel-for-pixel with the result and the visual difference view is misleading. The source image needs to retain the full comparison viewport width while only its clipping container changes width.
What changed
Code-quality and correctness
__tests__/directoriesAGENTS.mdWhy native Web Workers
The image pipeline is intentionally browser-local. BullMQ requires a Node.js service and Redis, which would upload or remotely process files and violate the current local-first scope.
Validation
pnpm validateValidation limitation
A browser automation smoke check could not run on this machine because no Chromium binary is installed.