Implement unit test for get_impacted_accounts() about bitshares-core

[vikramrajkumar]

From @theoreticalbts on July 29, 2015 18:9

Whoever writes test(s) to close this ticket will need to understand what the behavior of get_impacted_accounts() should be. In particular, we need to have a precise definition of the word "impacted."

Suppose Alice places an order, which matches an existing order placed earlier by Bob. Then Alice's account is impacted by her transaction because the order operation's execution will change her account's balance and set of owned objects regardless of chain state.

Even though the order changes Bob's account state as well -- his balances and his set of owned objects will be different -- Bob's account is not impacted by the order because Alice's order would also execute on a chain state in which Bob's order does not exist.

This example clearly shows that in this context, the word "impacted" must have a specific technical meaning different from ordinary English usage. The ordinary English definition of the word "impacted" would lead one to believe that both Alice and Bob are impacted by the order; the fact that Bob is not impacted is a direct consequence of the API design, where "impacted" is determined by inspection of the transaction and cannot refer to chain state.

Because get_impacted_accounts() has no access to the database, whatever definition of the word "impacted" we choose must include Alice and exclude Bob.

As @nathanhourt points out, changing the amount an account is allowed to withdraw causes the account to be impacted, without directly changing its set of owned objects or balances. The definition of the word "impacted" must work with this wrinkle as well (or the implementation needs to be changed to conform to the definition.)

We may be tempted to define "impacted accounts" to be the set of account ID's explicitly included in the operation. However, the transfer_operation has an implementation which contradicts this prospective definition:

void            get_impacted_accounts( flat_set<account_id_type>& i )const
{ i.insert(to); }

@nathanhourt also advises that an included-fields definition of "impacted" will open the door to tempting us to include account ID's in an operation solely because we want them to be returned by get_impacted_accounts(). Whether this is necessary to comply with the "Operations should be self-contained" project philosophy, or is unnecessary wire bloat and validation complexity, is a matter of opinion.

The real question, then, is where get_impacted_accounts() is used, and what the needs of that caller are. Which I will address in the next comment.

[vikramrajkumar]

From @theoreticalbts on July 29, 2015 18:34

get_impacted_accounts() is used by the API to determine when an API client subscribed to an account is notified of changes to an object. In particular, if operation O modifies a set of objects S, and account A is impacted by operation O, then listeners interested in account A will receive updates of S.

get_impacted_accounts() is also used by the account history plugin to determine the set of accounts whose most_recent_op is updated by an operation.

This design implies that there should be an API call to retroactively generate notifications for a client that has been offline, (kind of virtual notification queue). However, such an API has apparently not been implemented.

[vikramrajkumar]

From @theoreticalbts on July 29, 2015 18:51

Since it is only involved with API-level stuff (notifications and account history), I will move this logic out of the core and into the API.

[vikramrajkumar]

From @theoreticalbts on July 29, 2015 22:15

Possibly related: #166

[vikramrajkumar]

From @theoreticalbts on July 30, 2015 16:43

This is no longer part of the core, as of the above commit it's part of the app / API layer since it's used for notifications, nothing in the core.

[vikramrajkumar]

From @nathanhourt on July 30, 2015 18:17

This design implies that there should be an API call to retroactively generate notifications for a client that has been offline, (kind of virtual notification queue). However, such an API has apparently not been implemented.

I believe the intent is that clients can walk their accounts' operation history from most recent to last seen in order to get this queue.

[vikramrajkumar]

Consolidated into #219