With cider-20140528.928, decode errors on every operation #588
Comments
|
The doc string for one such problematic symbol: |
|
Looks like the info op returns the full metadata of a var, so here is the metadata for the above function. I suspect the issue is caused by the {:ns #<Namespace pallet.plan>,
:name execute-plan,
:file "pallet/plan.clj",
:column 1,
:line 190,
:arglists ([session target plan-fn]),
:doc
"Using the session, execute plan-fn on target. Uses any plan\n middleware defined on the plan-fn. Results are recorded by any\n recorder in the session, as well as being returned.\n\n## Function Signatures\n\n - BaseSession Target PlanFn -> (maybe PlanTargetResult)",
:sig
[[{:execution-state
{:executor pallet.core.executor.protocols.ActionExecutor,
{:k :recorder} pallet.core.recorder.protocols.Record,
{:k :action-options}
{{:p? #<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}},
{:k :user} {:_ nil},
{:k :environment} {:_ nil},
{:k :extension}
{{:p? #<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}},
{:k :record-all}
{{:p? #<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
java.lang.Boolean},
{:k :event-fn} {:_ nil}},
{:k :plan-state} pallet.core.plan_state.protocols.StateGet,
:type {:v :pallet.session/session}}
{{:p? #<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}}
{:output-schema {:_ nil},
:input-schemas
([{:schema
{:execution-state
{:executor pallet.core.executor.protocols.ActionExecutor,
{:k :recorder} pallet.core.recorder.protocols.Record,
{:k :action-options}
{{:p?
#<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}},
{:k :user} {:_ nil},
{:k :environment} {:_ nil},
{:k :extension}
{{:p?
#<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}},
{:k :record-all}
{{:p?
#<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
java.lang.Boolean},
{:k :event-fn} {:_ nil}},
{:k :plan-state} pallet.core.plan_state.protocols.StateGet,
:type {:v :pallet.session/session}},
:optional? false,
:name arg0}
{:schema {:_ nil}, :optional? false, :name arg1}])}
:-
{:schema
{:target
{{:p? #<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}},
{:k :action-results}
[{{:k :error} {:_ nil},
{:k :summary} {:schema java.lang.String},
{:p?
#<core$keyword_QMARK_ clojure.core$keyword_QMARK_@33a42080>,
:pred-name keyword?}
{:_ nil}}],
{:k :return-value} {:_ nil},
{:k :exception} java.lang.Exception}}]]} |
|
@hugoduncan Seems to me you're correct. It seem we'll have to do whitelisting of attributes allowed in the response (as opposed to the current blacklist approach). //cc @gtrak @jeffvalk |
|
@hugoduncan Btw, the number if the error is the point's position in the connection buffer (responses are inserted in the connection buffer, decoded and deleted; if something goes wrong the error reports the current position where something went wrong). I'll replace this with something more sensible. The encode/decode code needs a lot of love... |
|
The first thing I tried was a whitelist, unfortunately it excluded some We could make it a 'little' more robust, by simply excluding keys On Thu, May 29, 2014 at 7:24 AM, Bozhidar Batsov
|
|
The whitelist approach would force us, at least in a trivial sense, to define/document a schema for @gtrak Your original idea made good sense; if we can coordinate on keys, I certainly vote for this. |
|
👍 for a whitelist, no matter how long it would be. |
|
Since this is arbitrary metadata, there's still no guarantee that the user In addition to the whitelist, I think I should still do the dissoc'ing On Thu, May 29, 2014 at 9:24 AM, Bozhidar Batsov
|
|
+1 on silently dissoc'ing the troublesome entries. When this fails it leaves my emacs/cider unusable until I restart the JVM process. |
|
@gtrak @jeffvalk We should also add some check for incomplete messages (as nREPL streams the responses in chunks of 4k I think). Obviously we need a way to tell apart an incomplete message from a corrupted message. The lack of such mechanism got us into this predicament in the first place (the old code simply assumed that every decode error is an incomplete message). |
|
Time to implement core.async on elisp! ;-) On Friday, May 30, 2014, Bozhidar Batsov notifications@github.com wrote:
|
|
@gtrak I think an error I'm having may be related? Getting this on emacs GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.1) of 2014-05-14 on trouble, modified by Debian when calling cider-jack-in while having a file open in a leiningen project. Versions of CIDER related stuff is in the nrepl_decode function call. This appears to causes REPL error messages not to show up anywhere I can find them, with no other negative effects I have noticed (eldoc works, for instance). Output from valid code still shows up in the repl buffer. In addition, starting the REPL with cider-jack-in again gives me just an nrepl buffer, not a cider buffer and no error message. (As in the comment header is "; nrepl.el 0.2.0 (Clojure 1.6.0, nREPL 0.2.3)" with buffer name "nrepl learning-clojure" instead of "; CIDER 0.7.0alpha (package: 20140610.608) (Java 1.7.0_55, Clojure 1.6.0, nREPL 0.2.3, cider-nrepl 0.7.0-snapshot)" with buffer name "cider-repl learning-clojure") |
|
I think there are some edge-cases related to running cider-nrepl outside a On Tue, Jun 10, 2014 at 4:15 PM, Chris Carpenter notifications@github.com
|
|
@gtrak Well, it is in a lein project. I can't promise my settings are correct. I've got a global profiles.clj that says: Also, my lein project.clj is: |
|
@mordocai Seems you have |
|
@bbatsov @gtrak Does emacs have a way of specifying conflicting packages or is it possible to de-conflict nrepl from cider? One or the other should probably be done, I doubt i'm the only one who will run into this. |
|
@mordocai That's a known issue - #583. |
No, there's not such mechanism in |
With todays cider from melpa, the info op on some symbols seems to put cider into a state where all further operations result in an error.
The actual number seems to be monotonically increasing (but non-consecutive) with each operation.
The text was updated successfully, but these errors were encountered: