From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C938E4696C3 for ; Thu, 16 Apr 2020 22:48:37 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id r24so9213625ljd.4 for ; Thu, 16 Apr 2020 12:48:37 -0700 (PDT) Date: Thu, 16 Apr 2020 22:48:35 +0300 From: Konstantin Osipov Message-ID: <20200416194835.GA3623@atlas> References: <9ad134f42e6b11bf030f80d90435aac512db0784.1587058424.git.lvasiliev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ad134f42e6b11bf030f80d90435aac512db0784.1587058424.git.lvasiliev@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH V4 4/6] error: add session setting for error type marshaling List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Leonid Vasiliev Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * Leonid Vasiliev [20/04/16 20:45]: > Errors are encoded as a string when serialized to MessagePack to > be sent over IProto or when just saved into a buffer via Lua > modules msgpackffi and msgpack. > > That is not very useful on client-side, because most of the error > metadata is lost: code, type, trace - everything except the > message. > > Next commits are going to dedicate a new MP_EXT type to error > objects so as everything could be encoded, and on client side it > would be possible to restore types. > > But this is a breaking change in case some users use old > connectors when work with newer Tarantool instances. So to smooth > the upgrade there is a new session setting - > 'error_marshaling_enabled'. > > By default it is false. When it is true, all fibers of the given > session will serialize error objects as MP_EXT. I don't understand the point of having an MP_EXT if the same can be achieved with simply a new messagepack key. There is already IPROTO_ERROR_CODE, IPROTO_ERROR_MESSAGE, why can't you add IPROTO_ERROR_TYPE? And since this is a protocol change, there should have been (a short?) RFC for it. -- Konstantin Osipov, Moscow, Russia