Read client steps from remote config#6941
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
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. |
b6f6989 to
92899bf
Compare
Coverage report
Test suite run success3814 tests passing in 1458 suites. Report generated by 🧪jest coverage report action from d695822 |
ce4a75e to
4088d90
Compare
55fc27f to
b5573b3
Compare
| function parseClientSteps(clientSteps: string | null | undefined): ClientSteps | undefined { | ||
| if (!clientSteps) return undefined | ||
| return JSON.parse(clientSteps) | ||
| } |
There was a problem hiding this comment.
Unhandled JSON.parse can crash specifications fetch
clientSteps is sourced from a remote API field (spec.clientSteps) and is parsed with JSON.parse without a try/catch. If the API returns invalid JSON (e.g., empty string, partially-written JSON, a plain string, or an unexpectedly formatted value), JSON.parse will throw and the entire specifications() call will reject.
Evidence:
function parseClientSteps(clientSteps: string | null | undefined): ClientSteps | undefined {
if (!clientSteps) return undefined
return JSON.parse(clientSteps)
}This can make the CLI fail to fetch extension specifications, potentially breaking deploy/build flows for users receiving malformed clientSteps (or during a transient backend bug).
|
🤖 Code Review · #projects-dev-ai for questions ✅ Complete - 1 findings 📋 History✅ 1 findings |
4088d90 to
e9af6ce
Compare
b513dcb to
27d6a77
Compare
028d41e to
e312b08
Compare
27d6a77 to
c72d83b
Compare
e312b08 to
e60fc83
Compare
c72d83b to
9e042a7
Compare
9e042a7 to
6bf2ab6
Compare
e60fc83 to
9c2e1fd
Compare
6bf2ab6 to
fe8b229
Compare
8515fcc to
8a41de9
Compare
e6f3577 to
3f28156
Compare
8a41de9 to
e4825ef
Compare
3f28156 to
44034c5
Compare
526032a to
95bf05a
Compare
44034c5 to
094a68c
Compare
95bf05a to
65f7784
Compare
094a68c to
0478573
Compare
65f7784 to
fb7e81c
Compare
0478573 to
a8b39c0
Compare
fb7e81c to
cffedd1
Compare
74a2028 to
e39fbcd
Compare
d2eccd1 to
c707af8
Compare
5e27f1f to
e03b479
Compare
c707af8 to
0eb54f3
Compare
e03b479 to
ca267e2
Compare
0eb54f3 to
9eaca1c
Compare
ca267e2 to
991bfa9
Compare
9eaca1c to
0591ba8
Compare
991bfa9 to
c673b4a
Compare
0591ba8 to
8ccd857
Compare
8ccd857 to
d695822
Compare
c673b4a to
6a3974c
Compare
| identifier | ||
| externalIdentifier | ||
| features | ||
| clientSteps |
There was a problem hiding this comment.
I am worried about the coupling of client <> server we're doing here and the implications it has.

WHY are these changes introduced?
Extension specifications need to include client steps information to support build processes that require step-by-step client-side operations.
WHAT is this pull request doing?
clientStepsfield to the GraphQL query for fetching extension specificationsRemoteSpecificationinterface to include aclientStepsproperty of typeClientStepsAppManagementClientto convert the string-basedclientStepsfield from the API response into a structuredClientStepsarrayClientStepstype from the build services moduleHow to test your changes?
clientStepsfield is properly retrieved from the GraphQL APIMeasuring impact
How do we know this change was effective? Please choose one:
Checklist