Change call_order_update_operation to return order_id

[abitmore]

User Story

when there is a margin call fill order one of the fill orders references a 1.8.X call order which I can't find ever being created previously. This is messing with what I'm working at the moment which tracks orders and the time lines they're open for etc.

ID of call orders aren't returned when they're created nor updated:

bitshares-core/libraries/chain/market_evaluator.cpp

Line 194 in e2f33f5

void_result call_order_update_evaluator::do_apply(const call_order_update_operation& o)

It will help if the IDs are returned.

Note:

• operation_result is stored in block database, that means they won't be updated after a block get written to disk. If this feature is implemented, need a resync to update old data. Related code:

  bitshares-core/libraries/chain/include/graphene/chain/protocol/block.hpp

  Lines 52 to 56 in e2f33f5

  	struct signed_block : public signed_block_header
  	{
  	checksum_type calculate_merkle_root()const;
  	vector<processed_transaction> transactions;
  	};

• operation_result is being transmitted in P2P network since it's part of block_message, good news is they're not being verified so are not a part of consensus. In this code a processed_transaction is being used as a signed_transaction thus the operation_results field will be ignored:
  

  bitshares-core/libraries/chain/db_block.cpp

  Line 549 in e2f33f5

  processed_transaction database::apply_transaction(const signed_transaction& trx, uint32_t skip)

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
  • Assigned: @cogutvalera
  • Estimated: 2 hours
  • Remitted: Week 39
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[xeroc]

Why would we not extend the operation and let the user provide a 32bit value indexed in the database so orders can be identified by user-provided value?
Pretty much like it is done in Steem.

[abitmore]

@xeroc that's a good idea, but it needs a BSIP (#556). By the way, our object subscription/notification subsystem doesn't work well with self defined IDs so far. In the mean while, it's not hard for users to attach a custom_operation with arbitrary data to each operation, in the same transaction, for labeling purpose.

[cogutvalera]

@ryanRfox I want to claim this issue.

Thanks !

[ryanRfox]

@cogutvalera I've assigned this to you. Please provide an estimate prior to development. We want @bitshares/core-dev to review these. Please being with some test cases to ensure you are heading toward the intended solution. Thanks

[cogutvalera]

@ryanRfox my estimation for this issue is approximately 2 hours

[pmconrad]

Resolved through #1352

[cogutvalera]

Thanks !

[abitmore]

Update (important info):

• when a node received a block, it saves the block to disk "as is" after verified, so a resync won't cause a change in block database file;
• operation_result is used when calculating merkle tree, since merkle tree root is used to calculate block id, operation results of transactions in existing blocks should not be changed, otherwise old blocks will become invalid thus nodes will be unable to sync;
• operation results offered by witnesses are not verified; that said, operation_result stored in 1.11.x objects and those stored in blocks can be different e.g. due to different node versions (due to PR for this issue); we can add a check for this with a hard fork.