Wietse Wind
Wietse Wind
@NetScr1be Your example, `$GHOST`, is perfectly compliant providing it's not how it's stored on the XRPL: it's the text representation of the underlying XRPL value (HEX code) you are referring...
Thank you @scottschurr! Great solution, being able to configure alternative error codes per error. I see that you already added error codes for the most important errors/codes. Going through the...
Hi @scottschurr, sorry for that. Will do right now, lost track of this thread. Thanks for the reminder. I propose the codes below, where a non-standard HTTP code is only...
@scottschurr Thanks, appreciate it :D
Makes sense @mDuo13, thanks for chiming in. Thoughts regarding the version flag: if that same flag would also change the behaviour of other version related options, one would never be...
> Rebased to 1.9.2. @mDuo13 and @WietseWind, are you good with this version of the code? Thanks. Very happy with it :) Thank you!
> I agree that `tooBusy` should have a 50x status code. I don't know that every error should though. I don't think an account not found or transaction not found...
> Is this related to the recent scalability issues the XRPL has been having with Trustlines? No.
@intelliot Yes, I like that.
Addition: Currently, when a `subscribe` command is sent over a WebSocket connection to rippled, the direct response reflects the value provided in the `id` field when sending the subscribe command:...