Background
The chaos experiment methods in LitmusClient (e.g. listExperiment, saveChaosExperiment) already exist, but they have no dedicated SDK-level request DTOs. Callers must construct and pass loose generated *GraphQLQuery / *ProjectionRoot instances directly, which is verbose and inconsistent with the
User/Auth area (e.g. UserCreateRequest).
Proposal
Add builder-based request DTOs that wrap each operation's inputs (following the existing UserCreateRequest pattern), and update the corresponding LitmusClient methods to accept a single DTO instead of a query + projection root.
Targets:
listExperiment — DTO wraps projectID, the generated ListExperimentRequest filter payload, and a
ListExperimentProjectionRootsaveChaosExperiment — DTO wraps projectID and the generated SaveChaosExperimentRequest payload
(no projection)
Naming note
ListExperimentRequest and SaveChaosExperimentRequest already exist as generated GraphQL input types under io.litmuschaos.generated.types, and LitmusClientTest wildcard-imports both that package and io.litmuschaos.request.*. Reusing those exact names in the SDK request package would cause an ambiguous-reference compile error. The new DTOs therefore need distinct names — e.g.
ChaosExperimentListRequest / ChaosExperimentSaveRequest (domain-noun-first, consistent with PasswordResetRequest), or ListExperimentClientRequest / SaveChaosExperimentClientRequest. Open to whichever convention maintainers prefer.
Scope
src/main/java/io/litmuschaos/LitmusClient.javasrc/main/java/io/litmuschaos/request/- existing
*Response types look reusable, so no new response wrappers expected
Approach
I plan to replace the existing (query, projectionRoot) signatures rather than add overloads,
because:
- the SDK is still at
0.0.1, so a breaking change is acceptable at this stage
- keeping both styles makes the inconsistency between User/Auth and chaos-experiment APIs permanent
instead of resolving it
- callers retain full
projectionRoot control — it just moves inside the DTO
Happy to switch to an overload-based approach if maintainers prefer.
I'd like to work on this — please assign it to me. 🙂
Background
The chaos experiment methods in
LitmusClient(e.g.listExperiment,saveChaosExperiment) already exist, but they have no dedicated SDK-level request DTOs. Callers must construct and pass loose generated*GraphQLQuery/*ProjectionRootinstances directly, which is verbose and inconsistent with theUser/Auth area (e.g.
UserCreateRequest).Proposal
Add builder-based request DTOs that wrap each operation's inputs (following the existing
UserCreateRequestpattern), and update the correspondingLitmusClientmethods to accept a single DTO instead of a query + projection root.Targets:
listExperiment— DTO wrapsprojectID, the generatedListExperimentRequestfilter payload, and aListExperimentProjectionRootsaveChaosExperiment— DTO wrapsprojectIDand the generatedSaveChaosExperimentRequestpayload(no projection)
Naming note
ListExperimentRequestandSaveChaosExperimentRequestalready exist as generated GraphQL input types underio.litmuschaos.generated.types, andLitmusClientTestwildcard-imports both that package andio.litmuschaos.request.*. Reusing those exact names in the SDK request package would cause an ambiguous-reference compile error. The new DTOs therefore need distinct names — e.g.ChaosExperimentListRequest/ChaosExperimentSaveRequest(domain-noun-first, consistent withPasswordResetRequest), orListExperimentClientRequest/SaveChaosExperimentClientRequest. Open to whichever convention maintainers prefer.Scope
src/main/java/io/litmuschaos/LitmusClient.javasrc/main/java/io/litmuschaos/request/*Responsetypes look reusable, so no new response wrappers expectedApproach
I plan to replace the existing
(query, projectionRoot)signatures rather than add overloads,because:
0.0.1, so a breaking change is acceptable at this stageinstead of resolving it
projectionRootcontrol — it just moves inside the DTOHappy to switch to an overload-based approach if maintainers prefer.
I'd like to work on this — please assign it to me. 🙂