feat: Implement the new sale payment flow for the ticketing system #33
Conversation
|
I also think that the subcommands should be used within the |
| } | ||
|
|
||
| #[derive(candid::CandidType, candid::Deserialize)] | ||
| struct GetOpenTicketArg {} |
There was a problem hiding this comment.
| struct GetOpenTicketArg {} | |
| struct GetOpenTicketRequest {} |
| let req2 = sign_ingress_with_request_status_query( | ||
| pem, | ||
| "new_sale_ticket", | ||
| Encode!(&message)?, | ||
| TargetCanister::Swap(sns_canister_ids.swap_canister_id.get().0), | ||
| )?; |
There was a problem hiding this comment.
It seems like sns-quill makes this conditional message execution pretty difficult. I.e. if get_open_ticket does return a ticket id, then the subsequent call to new_sale_ticket will fail. This may be a confusing experience for users so I've asked Mario if he can introduce a third API to get_or_create. You can see the slack thread here https://dfinity.slack.com/archives/C03H6QEPW5D/p1675465230570649?thread_ts=1675169129.448279&cid=C03H6QEPW5D. If that change is impossible, I only see two ways of proceeding:
- Continue with what is already implemented. The user will have to parse the results.
- Separate these into two separate commands and have user understand the sale payment flow.
I think (1) is the best option right now but less than ideal. Lets see how he responds on Monday.
|
Since we merged |
Close SDK-953
The related argument/response types are not available in the mono-repo yet.
I manually defined the argument types which have been checked with the candid interface.
In
Sendsubcommand, I defined dummy structs for the response types.When the sale canister MR merged in the mono-repo, I will need to update the
ic-*dependencies and replace all definitions above with the formal ones.