Open dansteren opened 2 years ago
Have you tried this: https://github.com/dfinity/cdk-rs/blob/main/src/ic-cdk/src/api/call.rs#L636
I think @chenyan-dfinity was referring to #[query(manual_reply = true)]
and #[update(manual_reply = true)]
I use these and my exported interface contains multiple ManualReply
types.
However, it's not a problem for me because I'm not writing the exported service to disk; I'm comparing it with a hand-written file that's already on disk using service_compatible
.
@chenyan-dfinity I think I just accidentally left that attribute out somehow when making this issue, but yes, I am also using #[ic_cdk_macros::query(manual_reply = true)]
(See https://github.com/dansteren/candid_export_bug/blob/main/canisters/test/src/lib.rs#L8).
This does not fix the problem. The candid file still lists the type as ManualReply
instead of User
.
Describe the bug The candid export service doesn't correctly handle canister methods with a return type of ManualReply. Instead of exporting the record type in the canister method signature, it exports a generic
ManualReply
type. SubsequentManualReply
s will be given incrementing names of formatManualReply_n
where n increases for the amount of records.To Reproduce Steps to reproduce the behavior:
Create a Rust canister with the following contents:
Full example can be found at https://github.com/dansteren/candid_export_bug
Run
cargo test
Inspect the generated candid file at canisters/tests/test.did
Notice that it contains a type
ManualReply
which doesn't have the same name as theUser
struct in canisters/test/src/lib.rsExpected behavior The candid file should name the user type
User
notManualReply
. I.e.Screenshots N/A
Platform
Additional context The problem occurs regardless of whether the function is a Query or an Update. The problem does not occur if another function also returns that type (See https://github.com/dansteren/candid_export_bug/tree/include_type_in_other_function_sig).
PS: Your Bug issue template isn't working so I was unable to apply the
Bug
label.