Debugger issues when using prismatic/schema

[johnvictorfs]

Hello!

I really like the calva debugger feature, but most of the code I write in Clojure uses prismatic/schema to define and validate function parameters/schemas/returns etc. and it seems it doesn't work very well with the debugger. (Or I am doing something wrong)

(ns test)

#dbg
(defn sum
  [a b]
  (+ a b))

(sum a b) ; <- debugs just fine

(ns test
  (:require [schema.core :as s]))

#dbg
(s/defn sum :- s/Int
  [a :- s/Int
   b :- s/Int]
  (+ a b))

(sum a b) ; <- instantly tries to get into a breakpoint for the definition of 'sum' and weird things happen

I made a small sample repo: https://github.com/johnvictorfs/calva-debugger-repro and in the README there's a video of the issue happening

At least to me it seems really easy to reproduce, but it's also a bit inconsistent. Sometimes right after instrumenting the s/defn, resuming the instant breakpoint and then eval a call to it it works, but most of the time it happens the same as in the video below, where I am not able to break into the function when eval'ing (either with #dbg or "Instrument top level form for debugging")

I'm very much not a Clojure expert but digging around I found this in cider-nrepl that seems to attempt to fix this issue? But not totally sure what's happening https://github.com/clojure-emacs/cider-nrepl/blob/ec3e523d215dcae2183d20b6994eec7276751133/src/cider/nrepl/middleware/debug.clj#L596

Appreciate the help in advance!

[PEZ]

Hi! Thanks for reporting! 🙏

This bug is either in Calva or in cider-nrepl. To rule out cider-nrepl, we could have a look at the nrepl message log when this happens. You can enable this log in Calva via a command (not recalling the exact name, but you'll find it searching the command palette). Basically we expect the same kind of exchange for both your examples there. But if Calva is misreading/mistreating the messages we may see differences in the messages going from Calva to the nrepl server.

[johnvictorfs]

Thanks for the reply. If I got the log right, this is what's happening when I eval the s/defn expression with a #dbg (or I run the instrument command on it). I don't really know how to interpret this log, does this mean the issue is coming from cider-nrepl?

1760927127496 <- received 40811ms
{
  code: '#dbg\n(s/defn sum :- s/Int\n  [a :- s/Int\n   b :- s/Int]\n  (+ a b))',
  column: 1,
  coor: [ 1 ],
  'debug-value': '#function[simple-types/eval12309/sum--12314]',
  file: '/.../debugger-issue-repro/src/simple_types.clj',
  id: '8',
  'input-type': [
    'continue',       'locals',
    'inspect',        'trace',
    'here',           'continue-all',
    'next',           'out',
    'inject',         'stacktrace',
    'inspect-prompt', 'quit',
    'in',             'eval'
  ],
  key: 'cadbfce2-1480-46b0-8b30-16421280dc18',
  line: 4,
  locals: [
    [
      'ufv12303',
      '#object[java.util.concurrent.atomic.AtomicReference 0x347d1e0b "false"]'
    ],
    [
      'output-schema12302',
      '#Predicate{:p? #function[clojure.core/integer?], :pred-name integer?}'
    ],
    [
      'input-schema12304',
      '[#One{:schema #Predicate{:p? #function[clojure.core/integer?], :pred-name integer?}, :optional? false, :name a} #One{:schema #Predicate{:p? #function[clojure.core/integer?], :pred-name integer?}, :optional? false, :name b}]'
    ],
    [ 'input-checker12305', '#delay[<pending>]' ],
    [ 'output-checker12306', '#delay[<pending>]' ]
  ],
  'original-id': '29',
  'original-ns': 'simple-types',
  prompt: [],
  session: 'f68ef332-7d99-4d74-a161-67d7dec649d6',
  status: [ 'need-debug-input' ]
}

Edit: For now my terrible hacky workaround is using this fork that manually removes all the plumatic schemas before instrumenting 😅 dev...johnvictorfs:calva:dev not opening a PR with this change since I know this is not the proper way to fix this issue