Re: [Standards] XEP 313 error handling

[Kevin Smith]

On 14 Jan 2015, at 23:12, Matthew Wild  wrote:
> So are there any objections at all to removing  and switching
> back to the iq response signalling the end of results? If not, I'll
> change it in the next revision and the problem that started this
> thread will, I believe, be solved.

There’ve been no objections, so we’re intending to swap the message sentinel 
for the iq result again.

/K

Re: [Standards] XEP 313 error handling

[Kevin Smith]

On 16 Jan 2015, at 12:02, Florian Schmaus  wrote:
> I'd also like to discuss bundling the results. Leading to
> 
> request → result(1-x) → … → result(y-N) → end of results

I’m not keen on this, FWIW.

/K

Re: [Standards] XEP 313 error handling

[Florian Schmaus]

On 14.01.2015 20:51, Matthew Wild wrote:
> I am also in favour of the original protocol (iq result to signal end
> of result set), but also I feel like the behaviour Joe described is a
> perfectly reasonable thing to do, and XEP-0313 would be a singular
> problem for it.

Since there is a trend towards removing the  message and reverting
back to the former version, I'd like to point out, that what we see here
is not an uncommon pattern in XMPP. Basically every time an entity
requests an result set [1] you will have

request → result1 → … → resultN → end of results

I'd like to harmonize the protocol specifications in such cases and
suggest that 'request' is always an IQ and 'end of results' is the
corresponding IQ result to the request IQ.

IQ get id=42 → result1 → … → resultN → IQ result id=42

Implementations can easily circumvent possible timeout errors while
waiting for 'end of results' because of e.g. slow links or large result
sets, by resetting the timeout waiting for the IQ result every time a
result arrived. I don't like the idea of adding more complexity into a
XEP/specification just because some implementations would otherwise need
to change their code.

I'd also like to discuss bundling the results. Leading to

request → result(1-x) → … → result(y-N) → end of results

This would mean less work for the (intermediate) processors of the
stanzas and should be easily to implement.

The only problem I see is, that if such a result would contain a
'forwarded message' (if we think of the xep313 case) of a size close to
the lower bound of the maximum stanza size (1 bytes IIRC), then
bundling this message with another could result in a stanza that won't
get routed, while sending each 'forwarded message' individually would
cause no problems.

- Florian

1; We have this case at least in xep13, xep313 and possible xep60

Re: [Standards] XEP 313 error handling

[Matthew Wild]

On 14 January 2015 at 21:35, Kevin Smith  wrote:
> On 14 Jan 2015, at 19:51, Matthew Wild  wrote:
>> I am also in favour of the original protocol (iq result to signal end
>> of result set), but also I feel like the behaviour Joe described is a
>> perfectly reasonable thing to do, and XEP-0313 would be a singular
>> problem for it.
>
> I don’t think that’s true. There’s no guarantee of immediate response on any 
> iq, and although in most cases responses will be ~= immediate, there are 
> several that are likely to involve callouts to external services, disk reads 
> and waiting for responses in the same way as MAM.

I think you're probably right.

So are there any objections at all to removing  and switching
back to the iq response signalling the end of results? If not, I'll
change it in the next revision and the problem that started this
thread will, I believe, be solved.

Regards,
Matthew

Re: [Standards] XEP 313 error handling

[Kevin Smith]

On 14 Jan 2015, at 19:51, Matthew Wild  wrote:
> I am also in favour of the original protocol (iq result to signal end
> of result set), but also I feel like the behaviour Joe described is a
> perfectly reasonable thing to do, and XEP-0313 would be a singular
> problem for it.

I don’t think that’s true. There’s no guarantee of immediate response on any 
iq, and although in most cases responses will be ~= immediate, there are 
several that are likely to involve callouts to external services, disk reads 
and waiting for responses in the same way as MAM.

/K

Re: [Standards] XEP 313 error handling

[Matthew Wild]

On 14 January 2015 at 17:12, Florian Schmaus  wrote:
> On 04.12.2014 18:07, Kim Alvefur wrote:
>> On 2014-12-04 15:11, Kamil Kisiel wrote:
>>> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland >> > wrote: That's how it was specified in
>>> version 0.2, it seems it was changed to  in 0.3
>>
>> I remember someone argued very persistently that this change was
>> needed because their code had timeouts for iq requests that could
>> trigger if there is rate limiting or a slow connection before all
>> the messages and the iq-reply was received.
>>
>> Or something.  Personally I prefer having the iq-result sent last,
>> it makes client code (Verse in my case) simpler.
>
> Exactly my experience. I recently started working on xep313 in Smack,
> and if the iq response would signal the end of the messages the code
> would become less complex.
>
> I also don't see how using a message compared to an iq response yields
> any benefit when working on the xep313 client code. Only if your iq
> response timeouts are hard-coded maybe, but this appears to be a bad
> idea anyway.

Right. The issue was that the implementation Joe was referring to had
an API for sending iq stanzas, and it automatically raised a timeout
error if a response was not received within a certain period of time
(globally configured), on the assumption that the result stanza might
have been lost. This allows e.g. UI operations to not hang forever.

I am also in favour of the original protocol (iq result to signal end
of result set), but also I feel like the behaviour Joe described is a
perfectly reasonable thing to do, and XEP-0313 would be a singular
problem for it.

I'll note that we don't have to revert to the old protocol flow to
signal a failure in fulfilling the request. The iq response would
still mean "query was ok and now in progress" as now, and we could add
an attribute to  to indicate success or failure (i.e. the result
stream ended prematurely).

> Ideally xep313 implementations reset the timeout waiting for the final
> iq response every time an archived message is received.
>
> As a side note: xep13 uses the same approach (see § 2.6, example 11
> and 12).

Aha, thanks for pointing that out!

Regards,
Mattehw

Re: [Standards] XEP 313 error handling

[Florian Schmaus]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04.12.2014 18:07, Kim Alvefur wrote:
> On 2014-12-04 15:11, Kamil Kisiel wrote:
>> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland > > wrote: That's how it was specified in
>> version 0.2, it seems it was changed to  in 0.3
> 
> I remember someone argued very persistently that this change was
> needed because their code had timeouts for iq requests that could
> trigger if there is rate limiting or a slow connection before all
> the messages and the iq-reply was received.
> 
> Or something.  Personally I prefer having the iq-result sent last,
> it makes client code (Verse in my case) simpler.

Exactly my experience. I recently started working on xep313 in Smack,
and if the iq response would signal the end of the messages the code
would become less complex.

I also don't see how using a message compared to an iq response yields
any benefit when working on the xep313 client code. Only if your iq
response timeouts are hard-coded maybe, but this appears to be a bad
idea anyway.

It seems like a good idea for every xep313 client API to provide an
optional 'timeout' parameter, which defaults to the connections
default reply timeout, in order to give the user at least a chance to
work around problems caused by e.g. rate limiting or slow connections.
And in the end it doesn't make a difference if you use that timeout
waiting for the message with the  extension or the iq response.

Ideally xep313 implementations reset the timeout waiting for the final
iq response every time an archived message is received.

As a side note: xep13 uses the same approach (see § 2.6, example 11
and 12).

- - Florian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQF8BAEBCgBmBQJUtqOSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4
Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI414SUIAIrUFRLRTcR8gaRzsMx51JX5
uaPrB8q7zaJccHsQU/j8B3zFfy4hNnU1UzYOwVcGoLY4FJ8ZeUdBhRzPmJ27MKfv
6q7tliat78RsCqDsgoWTSa777H0P9Qljv4dhWssjAJJlDGJ3x4z0AWKZ9oEbh+8U
NKmf9b+OtT2vhWYksDFXm+NjI2APXfAwzRhFVIYmxo9XRXALa+8wVv0gyGGQmYCW
zDRwZaigCRZ6n4OZyNXoPBTrHYPJKYgEeeUCNvQs+CEaOj8kOe9UWfTdEuaG8Wfa
ZmjfR0mAaqYR8WTopZ6p7xmLqLJOzMz2QjEFz4iIIS438Ew6ZAhOY7AuuvY3pmQ=
=90ID
-END PGP SIGNATURE-

Re: [Standards] XEP 313 error handling

[Dave Cridland]

On 7 December 2014 at 12:31, Kevin Smith  wrote:

> I propose we roll back the sentinel and iq result handling to where they
> were originally, and have the iq terminate the results, either with a
> result (success) or error (failure).
>

I agree.

Partly because I think it's simpler in this case, and partly because as a
general protocol pattern, I would prefer  ->  -> , and I believe this is what our current
patterns are.

Dave.

Re: [Standards] XEP 313 error handling

[Kevin Smith]

On 4 Dec 2014, at 18:18, Curtis King  wrote:
>> On Dec 4, 2014, at 10:10 AM, Edwin Mons  wrote:
>> 
>> If you send back the iq result first, it will not be delayed further by all 
>> the result messages.  Why would there be an error during the message stream 
>> that would prevent you from returning an otherwise valid 313 response (or in 
>> an extreme case terminating the stream and making the point of properly 
>> finishing the messages moot?)
>> 
>> Most error cases will either happen before or at the moment when you 
>> actually start to find messages, e.g. authz issues or database issues.  Once 
>> you start sending back messages, or know there aren't any for a particular 
>> query, you can always present a valid message stream including a fin with an 
>> appropriate rsm set a client can use to continue a query should it choose 
>> to.  Note that the XEP allows you to return less items than the amount 
>> requested.
> 
> The issue is in most cases once you know the query will be successful you 
> have the messages to send. So, we are saving less than a second. Doesn’t seem 
> much of a saving.

Much as I know it pains everyone when Isode folks agree with each other, I 
agree with both Curtis and Edwin - returning the iq as the sentinel lets us use 
iq responses in the way they were intended - anything else is circumventing 
them.

I know that at the Summit, Joe spoke very strongly about the need for a 
sentinel message with an early-return iq, to avoid having to deal with special 
timeout code in a library he works with - after the last year of 
development/deployment experience I think we can now assert that moving the iq 
early effects the need for /more/ special-cased result-handling code, rather 
than less. If we continue with this patch, we will need to add error support to 
the sentinel, duplicating the iq semantics and requiring libraries to deal both 
with early iq errors and late message-based errors, and will need timeouts (if 
such things are necessary) to apply to both.

I propose we roll back the sentinel and iq result handling to where they were 
originally, and have the iq terminate the results, either with a result 
(success) or error (failure).

Would anyone support this, and does anyone oppose it? I’ve copied Joe as the 
previous opponent.

(I note, as others have, that there are other XEPs that involve data-fetching 
by the target from remote services or databases (particularly user search), and 
could trigger issues in libraries that require immediate response to iqs.)

/K

Re: [Standards] XEP 313 error handling

[Curtis King]

> On Dec 4, 2014, at 10:10 AM, Edwin Mons  wrote:
> 
> If you send back the iq result first, it will not be delayed further by all 
> the result messages.  Why would there be an error during the message stream 
> that would prevent you from returning an otherwise valid 313 response (or in 
> an extreme case terminating the stream and making the point of properly 
> finishing the messages moot?)
> 
> Most error cases will either happen before or at the moment when you actually 
> start to find messages, e.g. authz issues or database issues.  Once you start 
> sending back messages, or know there aren't any for a particular query, you 
> can always present a valid message stream including a fin with an appropriate 
> rsm set a client can use to continue a query should it choose to.  Note that 
> the XEP allows you to return less items than the amount requested.

The issue is in most cases once you know the query will be successful you have 
the messages to send. So, we are saving less than a second. Doesn’t seem much 
of a saving.

ck

Re: [Standards] XEP 313 error handling

[Edwin Mons]

On 04/12/14 18:57, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons  > wrote:
>
> On 04/12/14 18:07, Kim Alvefur wrote:
> > On 2014-12-04 15:11, Kamil Kisiel wrote:
> >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland
> mailto:d...@cridland.net>
> >> >> wrote:
> >>
> >>
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"
> mailto:kurt.zeile...@isode.com>
> >>  >> wrote:
> >> >
> >> > How does the server, after it has responded to the IQ
> with a type=result stanza, communicate errors in processing the
> query to the client that might subsequently occur.   What if the
> server is unable to send any subsequent stanzas associated with
> the query?  Is the server expected to hold off sending the IQ
> response until it is reasonable assured that no subsequent errors
> will occur?  That is, to the time in which has compiled all the
> stanzas to sends to the client and is ready to put them to XMPP
> stream?
> >> >
> >> > It seems to me that the IQ response really should come
> last so that the server is able to indicate to the client whether
> or not is has successfully completed the request or failed.   If
> sent last, then there’s really no need for a separate .
> >> >
> >> > If the IQ response is not last, there there really needs
> to be some method for the server to indicate that it’s not able to
> provide further results.
> >> >
> >>
> >> I think I agree with everything written here. Sending the
> iq last
> >> would be best, I think, though I appreciate that's likely
> to be a
> >> protocol bump.
> >>
> >> Dave.
> >>
> >> That's how it was specified in version 0.2, it seems it was
> changed to
> >>  in 0.3
> > I remember someone argued very persistently that this change was
> needed
> > because their code had timeouts for iq requests that could
> trigger if
> > there is rate limiting or a slow connection before all the
> messages and
> > the iq-reply was received.
> >
> > Or something.  Personally I prefer having the iq-result sent
> last, it
> > makes client code (Verse in my case) simpler.
> >
>
> I believe that was Joe.  Nowhere in the XEP do I see a requirement
> that
> the server should send back the IQ result (or error) immediately, just
> that it has to answer the IQ, send back messages, and terminate with a
> .  The example seems to hint at sending
> the iq
> result first, but nowhere does this claim you have to send back the iq
> result before making an attempt to generate results internally.  Only
> the examples hint that you should send back the iq result first, and
> indeed that was the intended behaviour as discussed at the summit.
>
> Edwin
>
>
>
> That seems a bit contradictory to me. If you can delay sending the
> result until all the messages have been sent, how does the 
> message solve the problem of timeouts waiting for the result iq? On
> the other hand if you are sending the iq result at the beginning to
> avoid the timeout, how do you indicate an iq error during the message
> stream? It doesn't seem clear what the answer is.

If you send back the iq result first, it will not be delayed further by
all the result messages.  Why would there be an error during the message
stream that would prevent you from returning an otherwise valid 313
response (or in an extreme case terminating the stream and making the
point of properly finishing the messages moot?)

Most error cases will either happen before or at the moment when you
actually start to find messages, e.g. authz issues or database issues. 
Once you start sending back messages, or know there aren't any for a
particular query, you can always present a valid message stream
including a fin with an appropriate rsm set a client can use to continue
a query should it choose to.  Note that the XEP allows you to return
less items than the amount requested.

Edwin

Re: [Standards] XEP 313 error handling

[Kamil Kisiel]

On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons  wrote:

> On 04/12/14 18:07, Kim Alvefur wrote:
> > On 2014-12-04 15:11, Kamil Kisiel wrote:
> >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  >> > wrote:
> >>
> >>
> >> On 3 Dec 2014 21:11, "Kurt Zeilenga"  >> > wrote:
> >> >
> >> > How does the server, after it has responded to the IQ with a
> type=result stanza, communicate errors in processing the query to the
> client that might subsequently occur.   What if the server is unable to
> send any subsequent stanzas associated with the query?  Is the server
> expected to hold off sending the IQ response until it is reasonable assured
> that no subsequent errors will occur?  That is, to the time in which has
> compiled all the stanzas to sends to the client and is ready to put them to
> XMPP stream?
> >> >
> >> > It seems to me that the IQ response really should come last so
> that the server is able to indicate to the client whether or not is has
> successfully completed the request or failed.   If sent last, then there’s
> really no need for a separate .
> >> >
> >> > If the IQ response is not last, there there really needs to be
> some method for the server to indicate that it’s not able to provide
> further results.
> >> >
> >>
> >> I think I agree with everything written here. Sending the iq last
> >> would be best, I think, though I appreciate that's likely to be a
> >> protocol bump.
> >>
> >> Dave.
> >>
> >> That's how it was specified in version 0.2, it seems it was changed to
> >>  in 0.3
> > I remember someone argued very persistently that this change was needed
> > because their code had timeouts for iq requests that could trigger if
> > there is rate limiting or a slow connection before all the messages and
> > the iq-reply was received.
> >
> > Or something.  Personally I prefer having the iq-result sent last, it
> > makes client code (Verse in my case) simpler.
> >
>
> I believe that was Joe.  Nowhere in the XEP do I see a requirement that
> the server should send back the IQ result (or error) immediately, just
> that it has to answer the IQ, send back messages, and terminate with a
> .  The example seems to hint at sending the iq
> result first, but nowhere does this claim you have to send back the iq
> result before making an attempt to generate results internally.  Only
> the examples hint that you should send back the iq result first, and
> indeed that was the intended behaviour as discussed at the summit.
>
> Edwin
>
>
>
That seems a bit contradictory to me. If you can delay sending the result
until all the messages have been sent, how does the  message solve
the problem of timeouts waiting for the result iq? On the other hand if you
are sending the iq result at the beginning to avoid the timeout, how do you
indicate an iq error during the message stream? It doesn't seem clear what
the answer is.

Re: [Standards] XEP 313 error handling

[Edwin Mons]

On 04/12/14 18:07, Kim Alvefur wrote:
> On 2014-12-04 15:11, Kamil Kisiel wrote:
>> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland > > wrote:
>>
>>
>> On 3 Dec 2014 21:11, "Kurt Zeilenga" > > wrote:
>> >
>> > How does the server, after it has responded to the IQ with a 
>> type=result stanza, communicate errors in processing the query to the client 
>> that might subsequently occur.   What if the server is unable to send any 
>> subsequent stanzas associated with the query?  Is the server expected to 
>> hold off sending the IQ response until it is reasonable assured that no 
>> subsequent errors will occur?  That is, to the time in which has compiled 
>> all the stanzas to sends to the client and is ready to put them to XMPP 
>> stream?
>> >
>> > It seems to me that the IQ response really should come last so that 
>> the server is able to indicate to the client whether or not is has 
>> successfully completed the request or failed.   If sent last, then there’s 
>> really no need for a separate .
>> >
>> > If the IQ response is not last, there there really needs to be some 
>> method for the server to indicate that it’s not able to provide further 
>> results.
>> >
>>
>> I think I agree with everything written here. Sending the iq last
>> would be best, I think, though I appreciate that's likely to be a
>> protocol bump.
>>
>> Dave.
>>
>> That's how it was specified in version 0.2, it seems it was changed to
>>  in 0.3
> I remember someone argued very persistently that this change was needed
> because their code had timeouts for iq requests that could trigger if
> there is rate limiting or a slow connection before all the messages and
> the iq-reply was received.
>
> Or something.  Personally I prefer having the iq-result sent last, it
> makes client code (Verse in my case) simpler.
>

I believe that was Joe.  Nowhere in the XEP do I see a requirement that
the server should send back the IQ result (or error) immediately, just
that it has to answer the IQ, send back messages, and terminate with a
.  The example seems to hint at sending the iq
result first, but nowhere does this claim you have to send back the iq
result before making an attempt to generate results internally.  Only
the examples hint that you should send back the iq result first, and
indeed that was the intended behaviour as discussed at the summit.

Edwin

Re: [Standards] XEP 313 error handling

[Kim Alvefur]

On 2014-12-04 15:11, Kamil Kisiel wrote:
> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  > wrote:
> 
> 
> On 3 Dec 2014 21:11, "Kurt Zeilenga"  > wrote:
> >
> > How does the server, after it has responded to the IQ with a 
> type=result stanza, communicate errors in processing the query to the client 
> that might subsequently occur.   What if the server is unable to send any 
> subsequent stanzas associated with the query?  Is the server expected to hold 
> off sending the IQ response until it is reasonable assured that no subsequent 
> errors will occur?  That is, to the time in which has compiled all the 
> stanzas to sends to the client and is ready to put them to XMPP stream?
> >
> > It seems to me that the IQ response really should come last so that the 
> server is able to indicate to the client whether or not is has successfully 
> completed the request or failed.   If sent last, then there’s really no need 
> for a separate .
> >
> > If the IQ response is not last, there there really needs to be some 
> method for the server to indicate that it’s not able to provide further 
> results.
> >
> 
> I think I agree with everything written here. Sending the iq last
> would be best, I think, though I appreciate that's likely to be a
> protocol bump.
> 
> Dave.
> 
> That's how it was specified in version 0.2, it seems it was changed to
>  in 0.3

I remember someone argued very persistently that this change was needed
because their code had timeouts for iq requests that could trigger if
there is rate limiting or a slow connection before all the messages and
the iq-reply was received.

Or something.  Personally I prefer having the iq-result sent last, it
makes client code (Verse in my case) simpler.

--
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature

Re: [Standards] XEP 313 error handling

[Kamil Kisiel]

On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland  wrote:

>
> On 3 Dec 2014 21:11, "Kurt Zeilenga"  wrote:
> >
> > How does the server, after it has responded to the IQ with a type=result
> stanza, communicate errors in processing the query to the client that might
> subsequently occur.   What if the server is unable to send any subsequent
> stanzas associated with the query?  Is the server expected to hold off
> sending the IQ response until it is reasonable assured that no subsequent
> errors will occur?  That is, to the time in which has compiled all the
> stanzas to sends to the client and is ready to put them to XMPP stream?
> >
> > It seems to me that the IQ response really should come last so that the
> server is able to indicate to the client whether or not is has successfully
> completed the request or failed.   If sent last, then there’s really no
> need for a separate .
> >
> > If the IQ response is not last, there there really needs to be some
> method for the server to indicate that it’s not able to provide further
> results.
> >
>
> I think I agree with everything written here. Sending the iq last would be
> best, I think, though I appreciate that's likely to be a protocol bump.
>
> Dave.
>
That's how it was specified in version 0.2, it seems it was changed to
 in 0.3

Re: [Standards] XEP 313 error handling

[Dave Cridland]

On 3 Dec 2014 21:11, "Kurt Zeilenga"  wrote:
>
> How does the server, after it has responded to the IQ with a type=result
stanza, communicate errors in processing the query to the client that might
subsequently occur.   What if the server is unable to send any subsequent
stanzas associated with the query?  Is the server expected to hold off
sending the IQ response until it is reasonable assured that no subsequent
errors will occur?  That is, to the time in which has compiled all the
stanzas to sends to the client and is ready to put them to XMPP stream?
>
> It seems to me that the IQ response really should come last so that the
server is able to indicate to the client whether or not is has successfully
completed the request or failed.   If sent last, then there’s really no
need for a separate .
>
> If the IQ response is not last, there there really needs to be some
method for the server to indicate that it’s not able to provide further
results.
>

I think I agree with everything written here. Sending the iq last would be
best, I think, though I appreciate that's likely to be a protocol bump.

Dave.

[Standards] XEP 313 error handling

[Kurt Zeilenga]

How does the server, after it has responded to the IQ with a type=result 
stanza, communicate errors in processing the query to the client that might 
subsequently occur.   What if the server is unable to send any subsequent 
stanzas associated with the query?  Is the server expected to hold off sending 
the IQ response until it is reasonable assured that no subsequent errors will 
occur?  That is, to the time in which has compiled all the stanzas to sends to 
the client and is ready to put them to XMPP stream?

It seems to me that the IQ response really should come last so that the server 
is able to indicate to the client whether or not is has successfully completed 
the request or failed.   If sent last, then there’s really no need for a 
separate .

If the IQ response is not last, there there really needs to be some method for 
the server to indicate that it’s not able to provide further results.

Anyways, I’ve implemented this, and for now we hold back the IQ response until 
we get the data from our internal archives and are otherwise ready to respond 
to the query.   This ensures that if we are generally able to provide an error 
response if any error happens to occur during the processing of the query.

— Kurt