Summary
The existing marketplace listing path reports that a listing was rolled back and releases its local claim even when compensating AWS cancellation fails. The external listing can remain active while the local row no longer records the new listing.
Found during independent final-HEAD review of LeanerCloud/cloud-commitments-cli#2077 at 899ab790d40cf4bf0475edd7cd32ce2f21481186; the same code is present in its base 81f2fc3ac44ce47221682fa1c50dec26e4f24eed. The IAM PR does not modify this handler.
Current behavior
internal/api/handler_marketplace.go:265-276, reserveAndCreateListing:
- AWS listing creation succeeds and returns a listing ID.
UpdatePurchaseHistoryListing fails to persist that result.- The compensating
CancelMarketplaceListing also fails.
- The handler logs cancellation failure, calls
releaseMarketplaceClaim anyway, and returns an error saying the listing has been rolled back.
If claim restoration succeeds, it restores the old listing fields despite the unresolved external listing. The response is inaccurate even when restoration fails. A later create attempt uses a fresh client token; whether AWS accepts another listing is not established here and no duplicate listing is claimed as an observed result.
Steps to reproduce safely
Use the existing handler/mock test infrastructure with a Standard RI, authorized session/account, successful claim and AWS create, then inject a DB result-save failure and a cancellation failure. Allow claim restoration to succeed. Assert returned error, stored listing state, call order, and retry behavior. Do not create a real marketplace listing to reproduce this.
Expected behavior
Report cancellation/rollback uncertainty honestly and keep enough ownership/state to reconcile the known external listing. Do not restore a safely-retryable local state while cancellation is unconfirmed. Also preserve correct behavior when compensation succeeds and when the database remains unavailable.
Proposed fix
Fix the failure branch in internal/api/handler_marketplace.go using the existing store/listing state model, then add handler-level regression coverage for create success plus DB failure plus cancellation failure. Verify the complete response and persisted state, not only the helper error. Decide the minimal recoverable-state treatment before changing the store contract; do not assume the unimplemented status poller already handles this path.
References
Severity
Medium, P2, this sprint, few users, small effort, bug. The reachable double-failure path can leave an externally active listing untracked and falsely report rollback. This is confirmed by source tracing, not a live AWS failure experiment.
Summary
The existing marketplace listing path reports that a listing was rolled back and releases its local claim even when compensating AWS cancellation fails. The external listing can remain active while the local row no longer records the new listing.
Found during independent final-HEAD review of LeanerCloud/cloud-commitments-cli#2077 at
899ab790d40cf4bf0475edd7cd32ce2f21481186; the same code is present in its base81f2fc3ac44ce47221682fa1c50dec26e4f24eed. The IAM PR does not modify this handler.Current behavior
internal/api/handler_marketplace.go:265-276,reserveAndCreateListing:UpdatePurchaseHistoryListingfails to persist that result.CancelMarketplaceListingalso fails.releaseMarketplaceClaimanyway, and returns an error saying the listing has been rolled back.If claim restoration succeeds, it restores the old listing fields despite the unresolved external listing. The response is inaccurate even when restoration fails. A later create attempt uses a fresh client token; whether AWS accepts another listing is not established here and no duplicate listing is claimed as an observed result.
Steps to reproduce safely
Use the existing handler/mock test infrastructure with a Standard RI, authorized session/account, successful claim and AWS create, then inject a DB result-save failure and a cancellation failure. Allow claim restoration to succeed. Assert returned error, stored listing state, call order, and retry behavior. Do not create a real marketplace listing to reproduce this.
Expected behavior
Report cancellation/rollback uncertainty honestly and keep enough ownership/state to reconcile the known external listing. Do not restore a safely-retryable local state while cancellation is unconfirmed. Also preserve correct behavior when compensation succeeds and when the database remains unavailable.
Proposed fix
Fix the failure branch in
internal/api/handler_marketplace.gousing the existing store/listing state model, then add handler-level regression coverage for create success plus DB failure plus cancellation failure. Verify the complete response and persisted state, not only the helper error. Decide the minimal recoverable-state treatment before changing the store contract; do not assume the unimplemented status poller already handles this path.References
known_issues/or the searched open issues.Severity
Medium, P2, this sprint, few users, small effort, bug. The reachable double-failure path can leave an externally active listing untracked and falsely report rollback. This is confirmed by source tracing, not a live AWS failure experiment.