Closed john-g-g closed 7 years ago
If steemd.steemit.com isn't reliable tell @jredbeard and he will fix it. I disagree that the solution is to fallback to a different staging deployment.
I encountered this will looping over accounts, when every so often the lib would return:
RPCError: 10 assert_exception: Assert Exception
itr != _by_name.end(): no method with name 'get_following'
{"name":"get_following","api":{"cancel_all_subscriptions":3,"get_account_bandwidth":45,"get_account_count":38,"get_account_history":40,"get_account_references":35,"get_account_votes":60,"get_accounts":34,"get_active_votes":59,"get_active_witnesses":70,"get_block":21,"get_block_header":20,"get_chain_properties":26,"get_comment_discussions_by_payout":8,"get_config":24,"get_content":61,"get_content_replies":62,"get_conversion_requests":39,"get_current_median_history_price":28,"get_discussions_by_active":11,"get_discussions_by_author_before_date":63,"get_discussions_by_blog":17,"get_discussions_by_cashout":12,"get_discussions_by_children":14,"get_discussions_by_comments":18,"get_discussions_by_created":10,"get_discussions_by_feed":16,"get_discussions_by_hot":15,"get_discussions_by_payout":6,"get_discussions_by_promoted":19,"get_discussions_by_trending":9,"get_discussions_by_votes":13,"get_dynamic_global_properties":25,"get_escrow":43,"get_expiring_vesting_delegations":49,"get_feed_history":27,"get_hardfork_version":30,"get_key_references":33,"get_liquidity_queue":52,"get_miner_queue":71,"get_next_scheduled_hardfork":31,"get_open_orders":51,"get_ops_in_block":22,"get_order_book":50,"get_owner_history":41,"get_post_discussions_by_payout":7,"get_potential_signatures":56,"get_recovery_request":42,"get_replies_by_last_update":64,"get_required_signatures":55,"get_reward_fund":32,"get_savings_withdraw_from":46,"get_savings_withdraw_to":47,"get_state":23,"get_tags_used_by_author":5,"get_transaction":54,"get_transaction_hex":53,"get_trending_tags":4,"get_vesting_delegations":48,"get_withdraw_routes":44,"get_witness_by_account":66,"get_witness_count":69,"get_witness_schedule":29,"get_witnesses":65,"get_witnesses_by_vote":67,"lookup_account_names":36,"lookup_accounts":37,"lookup_witness_accounts":68,"set_block_applied_callback":2,"set_pending_transaction_callback":1,"set_subscribe_callback":0,"verify_account_authority":58,"verify_authority":57}}
th_a api_connection.hpp:109 call
{"call.method":"get_following","call.params":["pionerr","pionerr","blog",0]}
th_a websocket_api.cpp:124 on_message
This was a mysterious error for me, so I think it would be even more of a problem for other/newer users.
Yes, steemd.steemit.com should always be up - if it's not, we have a giant problem. I think this is sufficient for the default steemd instance for the library.
https://steemd.steemit.com has been broken for the most of the day today (at least in the non-western world). The fallback to the staging node is what kept things operational for users of this library.
Furthermore, if the main nodes are functioning properly, the library should never fall-back to the staging node, making this change of defaults sort-of irrelevant.
@john-g-g I suspect the error you're referring to is an anomaly, caused by one of the nodes in the cluster having a follow plugin disabled, or not replayed properly.
@john-g-g I agree with you that using the staging node is a problematic solution, but given the historic issues with the main nodes, it is the best option we have for the time being.
Feel free to submit a new PR with different fallback node, but until the time the master nodes prove themselves reliable, I cannot accept above change.
The
steemd.steemitstage.com
instance shouldn't be in the default list becuase it may be running a different steemd version or doing any other thing that staging envs get up to.https://github.com/Netherdrake/steem-python/blob/master/steem/steemd.py#L55
should be: