microsoft
Driver Errors should expose implementation-specific details for hosts
Hosts know which driver implementation they are using, and may want to access driver-specific info from errors to improve serviceability.
Whereas, the FF Loader/Runtime have no interest in driver-specific implementation details, so it's not surprising that these details are "lost" (either missing altogether or just not exposed properly in the type system) by the time the errors pass through those layers and reach the host.
Examples would be knowing which specific service endpoint was being called with the failure happened. Or specific response header values such as sprequestguid.
Implementation Thoughts
We have an interface IOdspError which is used (poorly) to tack on one such property, serverEpoch. Instead, we could consider updating the base driver error types to include a property bag called specificDetails or some actual good name (type any). Then IOdspError would override that property with a narrower type, including any specific details that apply to ODSP driver errors. We would also export a type guard to narrow any ICriticalContainerError or IAnyDriverError to IOdspError, giving callers the confidence to inspect the object for that ODSP-specific info.
Related topics
Refactor APIs to a result-based model to return errors instead of throwing
We've discussed updating Driver APIs (and really all APIs) to return a result object encapsulating success or failure, rather than returning for success and throwing for failure. This would give strongly typed errors throughout, just like we're trying to achieve in this particular case.
Truncated driver callstacks in some applications using Fluid
In our experience building Microsoft Loops, the callstack on driver errors always stops within the driver code, omitting the outermost driver API that was called or any other host/runtime context. This makes it useless for diagnostics by partner teams. (There may not be anything to do in the FF repo for this, just taking a note here since it's related problem space.)
This issue has been automatically marked as stale because it has had no activity for 180 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!
