Giters

lambda-toolshed / papillon

Interceptor library for Clojure

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Resume on error

dmg46664 opened this issue · comments

commented

Hello,

So we've got a papillon scenario where we error a more involved pipeline of interceptors but still need to send a response which requires the last 3 interceptors in the chain.

We don't see this scenario handled/explored watching the section here.
https://youtu.be/bDN898hu_wQ?t=5088

Either this requires

  1. a retry-execute surrounding the execute
  2. Or the engine should retry by default unless the queue is specifically dequeued off the :lambda-toolshed.papillon/queue. It could still be moved elsewhere on the context for analysis.

I favour option 2. Curious to know if it was considered and rejected. In the spirit of thinking of the interceptor as CPU instructions, I don't see why having handled a problem, the process should not continue.

  1. Has the added advantage that superior error handlers may be lodged lower down on the stack from where the current error handler resumes. This would be removed on retry-execute and adding them back would be messy.

Given we are still on our own fork (as per #2 ), we are considering implementing 2. but thought it was only polite to discuss here 👼 .

Best,
Daniel

commented

Closing this issue.

We tried implementing our own version of solution (1) and found that it was a rabbit hole as you have to have rules to move forwards and backwards down the chain. In addition this required resetting aspects of the context, but that made understanding the history of the context more problematic.

It ended up being much simpler to handle any exception in individual interceptors and passing this error information forward in the context and following interceptors could handle as appropriately.

Sorry for any time wasted and thank you for indulging me.