You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a error is raised between calls to request_start and request_end or event_start and event_end, then there is no option for the event handler to register that this error occurred.
This is important, because _end methods are used to cleanup the resources (for example in OTel to mark span as failed and emit it to output). Without this, the handlers are not able to correctly close resources (if any) or register that failures happens.
The potential fix:
Introduce new methods for event handlers called:
request_failed
event_failed
That would capture the failures. The caller can invoke a method based on the execution flow. Moreover, event_failed does not correspond to request_failed, because if there was a failure for retrieving data for a collection, but a fallback worked, then we can have following event chain:
start -> retrieve from A (failed) -> retrieve from B (success) -> finish (success)
start -> retrieve from A (failed) -> retrieve from B (failed) -> finish (failed)
This would also be a good point in introducing error-as-value returns (like in Go, Scala, Haskell etc) when we would return either result or a failure (not necessarily a monad ;) ) to explicitly marked in the type system which operation are expected to failed and to force user to handle these errors (so they won't forget to call event_failed for example).
Traceback (most recent call last):
File "/home/bartoszmikulski/Repos/db-ally/error.py", line 86, in<module>asyncio.run(main())
File "/usr/lib/python3.10/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
returnfuture.result()
File "/home/bartoszmikulski/Repos/db-ally/error.py", line 80, in main
result = await collection.ask("What clients are from LA?", return_natural_response=True)
File "/home/bartoszmikulski/Repos/db-ally/src/dbally/collection/collection.py", line 204, in ask
view_result = await view.ask(
File "/home/bartoszmikulski/Repos/db-ally/src/dbally/views/structured.py", line 72, in ask
await self.apply_filters(iql)
File "/home/bartoszmikulski/Repos/db-ally/src/dbally/views/pandas_base.py", line 37, in apply_filters
self._filter_mask = await self.build_filter_node(filters.root)
File "/home/bartoszmikulski/Repos/db-ally/src/dbally/views/pandas_base.py", line 54, in build_filter_node
return await self.call_filter_method(node)
File "/home/bartoszmikulski/Repos/db-ally/src/dbally/views/methods_base.py", line 101, in call_filter_method
return method(*args)
File "/home/bartoszmikulski/Repos/db-ally/error.py", line 67, in filter_by_city
raise ValueError("ups - db error")
ValueError: ups - db error
The text was updated successfully, but these errors were encountered:
What happened?
When a error is raised between calls to
request_start
andrequest_end
orevent_start
andevent_end
, then there is no option for the event handler to register that this error occurred.This is important, because
_end
methods are used to cleanup the resources (for example in OTel to mark span as failed and emit it to output). Without this, the handlers are not able to correctly close resources (if any) or register that failures happens.The potential fix:
Introduce new methods for event handlers called:
request_failed
event_failed
That would capture the failures. The caller can invoke a method based on the execution flow. Moreover,
event_failed
does not correspond torequest_failed
, because if there was a failure for retrieving data for a collection, but a fallback worked, then we can have following event chain:This would also be a good point in introducing error-as-value returns (like in Go, Scala, Haskell etc) when we would return either result or a failure (not necessarily a monad ;) ) to explicitly marked in the type system which operation are expected to failed and to force user to handle these errors (so they won't forget to call
event_failed
for example).How can we reproduce it?
Relevant log output
The text was updated successfully, but these errors were encountered: