The scenario you describe will not happen with the existing guaranteed responses. But, as Austin says, it is possible for canister B (if it has enough cycles) to just spin forever (making downstream calls of its own) and to never produce a response. Which will make your canister impossible to stop. Also, even after canister B has produced a response, while there’s a guarantee that the response will be delivered, there is no guarantee regarding how long it takes to deliver said response.
Leaving aside the fact that the IC’s messaging layer guarantees response delivery, what you describe is something that virtually every single distributed system has to deal with: there is no such thing as guaranteed message delivery unless you’re willing to wait arbitrarily long. And a system that takes arbitrarily long to do even the simplest thing is not a very useful system. Just how likely would you be to use this forum if every 10th interaction took a few hours?
Also, this is exactly how ingress messages work: you send an ingress message; it is executed and the response certified; you have exactly 5 minutes to query for its status. If your internet connection goes down for 5+ minutes, you will never find out what the response was. If your canister does not provide an alternative way of learning the outcome, then you have not built a very useful application.
That would be an actively hostile API, unless there was some side channel to query for the status of your request (such as a ledger you can scan for your transaction). It’s a bit (or very much) like having an endpoint that replies with “I won’t tell you the outcome” on every single call.