Exception handling in pathom3 resolvers?

[wardle]

Hi Wilker. Amazing work with pathom3 - really exciting to see. I've been testing pathom3 as a way to abstract across multiple backend services in healthcare. The idea of resolving using a namespace / identifier much like that in ontologies such as RDF and then navigating a graph is compelling, providing different facades over the same backend data. I've read your post about error handling but I'm worried about the silent nature of exceptions in a resolver. In development, I need to fail fast, and yet at the moment, when using git head, an exception results in an empty result. I need to be able to know about failures, report them to the log (and to me in development). So as an example, this resolver runs against a backend health patient administrative system to return patient information. I plan on being able to resolve both HL7 FHIR properties as well as some RDF properties and the original source format.

(pco/defresolver
  cav-patient
  "Resolve a patient against the NHS Wales' Cardiff and Vale patient
  administrative system using the namespaced identifier specified."
  [env {:wales.nhs.cavuhb.id/keys [pas-identifier]}]
  {::pco/output [:FIRST_FORENAME :LAST_NAME :HOSPITAL_ID]}
  (let [opts (get-in env [::config :wales.nhs.cavuhb/pms])]
    (println "resolving real CAV identifier " pas-identifier " with opts" opts)
    (cav/fetch-patient-by-crn opts pas-identifier)))

Now if cav/fetch-patient-by-crn fails, I just get nothing.

e.g. at the REPL, when the cav/fetch-patient-by-crn fails because of network connectivity problems:

(p.eql/process env [{[:wales.nhs.cavub.id/pas-identifier "A999998"] [:FIRST_FORENAME]}])
resolving CAV identifier  A999998 opts: {:database vpmslive.world, :user-string patientcare-concierge, :username ******, :password ******}
=> {[:cav/pas-identifier "A999998"] {}}

My code (using pathom2 so far in committed code - my pathom 3 experiments are local only) - https://github.com/wardle/concierge and I plan on adding graph resolution across other services including https://github.com/wardle/clods (currently using pathom 2) and https://github.com/wardle/hermes

What are the options here?

I realise that there may be a security risk in sending detailed exception reporting to a client. So we need to somehow allow the server to control that handling, because in many situations we might like to summarise the issue - particularly if one expects to have authenticated and authorised clients. I could use try / catch in each resolver - but that is burdensome for the software developer. I could simply report an exception against an individual property - but that doesn't work for this use-case where the last function returns a map or throws an exception. Are there any other hooks I can use to catch, log and handle exceptions in a resolver like this?

[wilkerlucio]

Hello Mark, thanks for taking the time to write. There are a few ways you can see the errors in Pathom 3, I very recently added a few built-in plugins, and they should help with making the errors visible.

Here you can find the built-in plugins: https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/built_in/plugins.cljc

The setup I suggest for prod looks like this:

(def env
  (-> (pci/register ...)
      (p.plugin/register 
        [pbip/remove-stats-plugin 
         (pbip/attribute-errors-plugin)])))

Note: the plugin order is really important in this case (if you swipe the order, the errors will be missing, you can find more about plugin order evaluation here: https://pathom3.wsscode.com/docs/plugins#plugin-order)

The combination of these two plugins will expose the errors as data, and at the same time remove all the tracking information, in prod you really don't want to flow dev, but in dev, you do (so you may want to configure to include the remove-stats-plugin only in prod, or create some way for devs to run without it, for dev these stats power the Pathom Viz tools).

Another thing you can do if you like to track all errors is to write a plugin to do so. It looks like this:

(p.plugin/defplugin error-tracker-plugin
  {::pcr/wrap-resolver-error
   (fn [mark-error]
     (fn [env node e]
       (println "ERROR HAPPENED" e)
       (mark-error env node e)))})

This method is recommended if you are going to log errors in some external service.

Please let me know if these suffice for your case, or more is needed.

[wardle]

Thank you so much Wilker. I will test these out and it sounds as if they will solve the issue. Thank you, Mark

…

On Sun, 24 Jan 2021 at 18:45, Wilker Lúcio ***@***.***> wrote: Hello Mark, thanks for taking the time to write. There are a few ways you can see the errors in Pathom 3, I very recently added a few built-in plugins, and they should help with making the errors visible. Here you can find the built-in plugins: https://github.com/wilkerlucio/pathom3/blob/master/src/main/com/wsscode/pathom3/connect/built_in/plugins.cljc The setup I suggest for prod looks like this: (def env (-> (pci/register ...) (p.plugin/register [pbip/remove-stats-plugin pbip/attribute-errors-plugin]))) Note: the plugin order is really important in this case The combination of these two plugins will expose the errors as data, and at the same time remove all the tracking information, in prod you really don't want to flow dev, but in dev, you do (so you may want to configure to include the remove-stats-plugin only in prod, or create some way for devs to run without it, for dev these stats power the Pathom Viz tools). Another thing you can do if you like to track all errors is to write a plugin to do so. It looks like this: (p.plugin/defplugin error-tracker-plugin {::pcr/wrap-resolver-error (fn [mark-error] (fn [env node e] (println "ERROR HAPPENED" e) (mark-error env node e)))}) This method is recommended if you are going to log errors in some external service. Please let me know if these suffice for your case, or more is needed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#15 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGBZ3LILHPP7QW3LZ4UKDS3RTEJANCNFSM4WQW6BCQ> .