From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id DB81F46970E for ; Wed, 29 Jan 2020 17:36:07 +0300 (MSK) Date: Wed, 29 Jan 2020 17:36:06 +0300 From: Nikita Pettik Message-ID: <20200129143606.GC1049@tarantool.org> References: <3f49ddc14c2e07f4ac96fc71f3912fd0c5663882.1579032293.git.korablev@tarantool.org> <26c58292-4720-49b0-0770-6bafb559936f@tarantool.org> <20200127112337.GE1144@tarantool.org> <2807ea8a-9251-0191-3321-6c87a4c5bb09@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2807ea8a-9251-0191-3321-6c87a4c5bb09@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] box: rfc for stacked diagnostic area List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org On 28 Jan 01:23, Vladislav Shpilevoy wrote: > Hi! Thanks for the fixes! > > It is not a second review. I just wanted to say that I am > going to spend less time on reviewes to the end of this > week due to intensive preparations to FOSDEM. I will get > back to this RFC as soon as I can, I didn't forget. > > Just one comment for now, below. > > >>> +* **Issues**: [#1148](https://github.com/tarantool//issues/1148) > >>> + > >> > >> 2. You missed 'Summary' section. > > > > I believe it is redundant for such brief RFC. > > > > Nevertheless, please, add it. If that RFC is so simpler, > then it should not be a problem to make it match the > RFC template. Template says: > > "Short description what, why and how is implemented." > > So just say something like > > The document describes a stacked diagnostics feature. The > feature is needed for the cases, when there is a complex and > big callstack with different subsystems in it, and sometimes > the most lowlevel error is not descriptive enough. So it is > wanted to be able to look at errors along the whole callstack > from the place where a first error happened. The feature > implementation is going to change a fiber's error object to a > list of objects, a stack. Its first element will always be > created by the deepest and the most basic errors. > > Or anything you think would be better here. Ok, as you wish. A bit reformulated your description: diff --git a/doc/rfc/1148-stacked-diagnostics.md b/doc/rfc/1148-stacked-diagnostics.md index 0d1d07dc3..d57e040ba 100644 --- a/doc/rfc/1148-stacked-diagnostics.md +++ b/doc/rfc/1148-stacked-diagnostics.md @@ -6,6 +6,18 @@ Pettik Nikita @Korablev77 korablev@tarantool.org * **Issues**: [#1148](https://github.com/tarantool//issues/1148) + +## Summary + +The document describes a stacked diagnostics feature. It is needed for the cases, +when there is a complex and huge call stack with variety of subsystems in it. +It may turn out that the most low-level error is not descriptive enough. In turn +user may want to be able to look at errors along the whole call stack from the +place where a first error happened. In terms of implementation single fiber's +error object is going to be replaced with a list of objects forming diagnostic +stack. Its first element will always be created by the deepest and the most +basic error. Both C and Lua APIs are extended to support adding errors in stack. +