(In return, note that Cap 'n Proto's A -> D message makes it more obvious how A figures out whether the operation succeeded; I'm not quite sure how that works in the proposed diagram. I suppose the proposed system actually puts all messages in a system-wide database, which does solve the problem.)
That should not be the case with promise pipelining. The "Mobile Almost-Code" section of the E page explains this. You mentioned "continuation passing style", which is effectively what promise pipelining does: For the constrained class of continuations that can be serialized as a dataflow graph, pass those along with the message.
Importantly, the system wide constraint is willing participation from each actor, not a shared database. Instead of each actor needing to know how to interact with the shared database, each actor needs to be willing and able to execute these passed continuations.
Essentially, there are sometimes big, systemic, intractable problems that lower-level people might see but not have the perspective, experience, etc. to even begin coming up with a solution. Higher-level people might have the perspective and experience but not see those problems (especially as each layer of the hierarchy acts a filter or sugar-coating mechanism for bad news as it moves upwards). If you tell people not to report problems unless they have a solution, and summarily dismiss anyone who does so, some serious problems might just be left rotting.
> What am I going to do if I agree with you?
A reasonable response to this might actually be, "I don't know; isn't that why you get paid the big bucks and I don't?"
Reporting problems with proposed solutions should be encouraged, but there shouldn't be a blanket statement of "Don't bring a me problem unless you have a proposed solution!" An executive can simply ask, "Do you have a proposal?" and if the answer is negative the executive can say, "I understand, interesting, thanks for reporting this. I'll keep it in mind / assign someone more senior on my staff to look into it / etc."
Some other useful intermediate proposals include:
- "Allow me and my team time to investigate a solution."
- "I've organized my complaints into requirements for a solution. Please identify an expert to solve the problem."
- "I've socialized these problems with ${people}, I recommend you speak to ${person} about ${topic} for next steps."
Having said that, I agree that complaints can be counted as "votes" for which problems to solve in the future. The problem is that they are not one complaint = one vote. At the very least, the complainer's role and responsibilities need to be accounted for within the scope of the larger organizational goals.