-
Notifications
You must be signed in to change notification settings - Fork 223
Quick-watch: Catch early bulk operation errors without --watch
#6687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
--watch
abd87e4 to
fe2d0bb
Compare
|
We detected some changes at Caution DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release. |
Coverage report
Show new covered files 🐣
Show files with reduced coverage 🔻
Test suite run success3544 tests passing in 1414 suites. Report generated by 🧪jest coverage report action from 910f6b0 |
packages/app/src/cli/services/bulk-operations/watch-bulk-operation.ts
Outdated
Show resolved
Hide resolved
packages/app/src/cli/services/bulk-operations/watch-bulk-operation.ts
Outdated
Show resolved
Hide resolved
packages/app/src/cli/services/bulk-operations/execute-bulk-operation.ts
Outdated
Show resolved
Hide resolved
jordanverasamy
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder how much the extra polling (seems like right now we poll 10 times in a 3 second period) actually helps. Would be simple and nice to just e.g. wait 1 second and fetch once, instead of doing all of that work, and I bet it'd cover most of the same common cases anyways. What are your thoughts on the tradeoffs there?
e27a952 to
cf26356
Compare
|
Are there any impactful consequences with extra polling? Does it slow anything down or put too much pressure on the platform or something? Tbh, I don't think I know enough about the speed of the API, the user/agent's needs, or the impact of the extra polling to decide this. Happy to refactor either way though! |
packages/app/src/cli/services/bulk-operations/watch-bulk-operation.ts
Outdated
Show resolved
Hide resolved
packages/app/src/cli/services/bulk-operations/execute-bulk-operation.ts
Outdated
Show resolved
Hide resolved
fa74da9 to
b0b505d
Compare
packages/app/src/cli/services/bulk-operations/execute-bulk-operation.ts
Outdated
Show resolved
Hide resolved
packages/app/src/cli/services/bulk-operations/watch-bulk-operation.ts
Outdated
Show resolved
Hide resolved
5f8926e to
d0fe8d1
Compare
d0fe8d1 to
84d9954
Compare
Not really, it's not that many requests in the grand scheme of things. IMO the real cost there is code complexity and developer brainpower, not platform pressure. But that said I'm happy with keeping it and like where we landed, so don't worry :) |
84d9954 to
fb8280d
Compare
65302ac to
4b4ce44
Compare
gonzaloriestra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice solution! It works well.
But I agree with @jordanverasamy that the current polling is maybe excessive, even if it won't cause problem. I think a 1s polling interval should be enough and consistent with #6695
4b4ce44 to
910f6b0
Compare

Resolves: https://github.com/orgs/shop/projects/208/views/34?filterQuery=&pane=issue&itemId=140129246&issue=shop%7Cissues-api-foundations%7C1123
Inspired by: https://github.com/shop/issues-api-foundations/issues/1123#issuecomment-3603641001
Background
When users run bulk operations with
--variablesor--variable-file, invalid JSON or malformed inputs aren't validated upfront. Without the--watchflag, users would:This is a frustrating experience, especially for long-running bulk operations.
We considered validating JSON on the client before sending to the API, but:
The solution: Quick-watch
Instead of duplicating validation logic, we leverage the fact that errors tend to surface in the first 2-3 seconds of a bulk operation. By polling briefly after creation, we can catch most "obvious issues" (like malformed JSON) and present them immediately—without requiring users to run a second command or wait for hours.
This approach:
Implementation Details
Detecting mutation-level errors in results
When a bulk operation completes
(status: COMPLETED), we check the downloaded results foruserErrorsusing a simple string check:results.includes('"userErrors":[{').This catches cases where the operation "succeeds" but individual mutations failed (e.g., malformed JSON variables). Instead of showing a misleading "Bulk operation succeeded" message, we show:
renderWarningwith "Bulk operation completed with errors."--output-filewas provided: includes the file path so users know where to checkWhy
.includes()instead of?.userErrors?.length:like in line 62 ofexecute-bulk-operation.ts?The result file is a raw JSONL string, not a JavaScript object. Parsing every line would be expensive for large files — a simple string search is O(n) with no allocations. Checking for "userErrors":[{ only matches non-empty arrays ("userErrors":[] won't match).
Flag behavior
Quick watch only happens when the
--watchflag isn't given. This decision is explained here.Polling configuration
QUICK_WATCH_TIMEOUT_MS = 3000- Total time to pollQUICK_WATCH_POLL_INTERVAL_MS = 300- Poll every 300ms (~10 polls max)No null checks in
quickWatchBulkOperation:We use
bulkOperation!(non-null assertion) because:executeBulkOperationalready checksuserErrorsbefore calling quick-watchbulkOperationis null,userErrorswould exist and we'd return earlyTophatting
For catching errors early:
This is what my
results.jsonllooked like:For super quickly finished bulk operations that successfully finish within the quick-watch:
For bulk operations that do not finish in quick-watch:
Create a variable file:
Run the long bulk mutation: