~singpolyma/sgx-jmp

ref: f571b5e726750cf8c4523c22d77e110194c3e16a sgx-jmp/lib/command.rb -rw-r--r-- 3.7 KiB
Merge branch 'monthly-billing'

* monthly-billing:
  Allow the DB to notify us to bill a customer
  Command.execution setter
  Bill plan command
  Clearer name for lock bypass factory
Command.execution setter
Respond to Proper Cancel Stanza

Previously cancels would be treated as an error, but then would be
caught so that they could respond with receipt of the cancel later.

But, we weren't setting @iq in these cases, because it was an error, so
we would actually respond to the wrong stanza; specifically the one
before the cancel.

This was bad and wrong and led to the bot sitting there waiting for the
cancel before moving on with its life.
Merge branch 'rubocop'

* rubocop:
  Additional fixes for rubocop 1.10.1
  Switch to rubocop 0.89.1
Additional fixes for rubocop 1.10.1

This is the default rubocop in Guix.
Switch to rubocop 0.89.1

This is the rubocop in new Debian stable
Move CustomerFwd behind Customer

All the previously-lazy BackendSgx data is now either all loaded or all not
loaded by swapping the sgx_repo used by your CustomerRepo instance.  When not
loaded the fields are filled with bottom values that explode when used.  When
loaded the values are present in RAM and not promises at all.  Most code paths
do not need any of the data, a few need most of it, so this seems like a good
trade-off.  Most code using this object will simply never touch those fields or
care about how they are loaded, etc.

Of course, most of this data isn't even SGX related and should move out of here,
but that would take a data model refactor/migration on the catapult_* schema.
Merge branch 'cancel-timeout'

* cancel-timeout:
  Timeout is not a fatal error
  When user cancels the command, respond with canceled
Timeout is not a fatal error

If the user does not proceed with a command after N time, we don't hold on to it
forever and time out.  We cannot return anything to the user because they
haven't sent us anything, so just ignore it.
When user cancels the command, respond with canceled

If the cancel has not been fully handled in the body of the command, at least
respond with canceled status and do not go to sentry.
Merge branch 'command-object'

* command-object:
  ErrorToSend => FinalStanza
  Since Command#finish causes an error, a then off the end won't work
  Refactor commands to have Command and Command::Execution objects
ErrorToSend => FinalStanza
Refactor commands to have Command and Command::Execution objects

Brings the common elements of all commands together, and threads the most useful
state (such as ability to reply) through automatically using the new EMPromise
fiber trampoline.