或许有细心的朋友会注意到，昨天很多帖子的得票都要比前些天少一些。
是因为币价下跌导致大家无心投票嘛，答案是否定的。

get_ops_in_block 出毛病了

那么真实的情况是什么呢？那要先从我的点赞机器人(Curation Bot)说起。昨天一早起来关注了一下我的机器人，然后发现程序在跑着，但是既然一个POST也没抓到，看了一下日志，从7月11号凌晨起就没有数据进来，这不科学啊，不是每三秒一个block嘛，看STEEMIT上帖子和回复这么呢，我咋就一个没抓到呢？

不信邪，写了个简化的程序，还是没数据进来。
于是乎在测试环境下开始漫长的调试之旅，最后发现其它功能都正常，唯独：get_ops_in_block 这个API有毛病

      /**
       *  @brief Get sequence of operations included/generated within a particular block
       *  @param block_num Height of the block whose generated virtual operations should be returned
       *  @param only_virtual Whether to only include virtual operations in returned results (default: true)
       *  @return sequence of operations included/generated within the block
       */
       vector<applied_operation> get_ops_in_block(uint32_t block_num, bool only_virtual = true)const;

看一下steem代码中的定义和描述
这个API的功能就是把指定块(block)中的操作(operations)顺序取出。

而它出了啥毛病呢，举例说，一个块中会有一系列操作（发帖、回复、点赞、转账等等)，可能多达几十上百个。没出问题的时候，这些操作都会被顺序取出，而11号凌晨出毛病之后，只返回零星的几个操作。就是说大部分操作被它搞丢了 😡

get_ops_in_block 如何影响机器人

点赞机器人的工作原理：

1. 挨个块遍历
2. 把块中操作取出
3. 如果有comment操作(发帖或回复)，则交由程序其它部分判断是否点赞

因为get_ops_in_block 把大部分操作搞丢了，所以在第二步我们几乎没有取回任何操作，就甭提第三步的判断了。

然后，机器人就瞎了。STEEM网上有很多机器人应该是基于get_ops_in_block这个 API的，于是，就都瞎了。这也是点赞数变少的原因。

如何解决和避免

方法一： 换节点

发现这个问题以后，我测试了官网的几个节点，不出意料的全坏掉了。
然后又找了一堆第三方提供的节点，嗯，有两个还好用

• gtg.steem.house:8090
• seed.bitcoiner.me

但是不知道是不是我心里因素，总觉得这两个节点响应速度没官网的快呢，5555

方法二： 读回整个块

虽然get_ops_in_block 不好用了，但是测试了一下get_block还好用
所以另外一种方法就是弃用get_ops_in_block，用get_block读回整个块再处理
似乎数据量比前一种方法大了些(多出witness信息、签名信息等等)，但是似乎也不是忍受不了

方法三： 静等修复

懒人的终极大法，除非是steemit官方刻意让这个API不好用，否则有问题他们都会去修复的，耐心等待即可。

方法四： 自己跑节点

呃，想想就头疼，能不自己跑，还是先偷懒吧

其它影响

我有测试除了上述API外，其它常用的功能都依然正确，所以如果不是从块中读数据或者同步数据，那么基本上不受啥影响。但是需要从块中读数据的可就不好说啦。

steemdata

• 文章数据
  7月11日全天读入的文章数据：8601
  而7月10日这个值为： 16810

• 点赞数据
  7月11日全天 点赞数： 97753
  而7月10日这个值为： 271373
  更恐怖的是在2017-07-11 0时至2017-07-11 17:00:00 (UTC) 点赞数据为空哦

以上数据一方面说明 get_ops_in_block API 造成的影响巨大，也说明了Steemdata 还有待完善。

SteemData Notify

我们之前对SteemData Notify 做过一些学习，清楚的知道，SteemData Notify 读取区块链上的操作所用的机制就是get_ops_in_block API，那么这段时间用户设置能否得到确认，或者用户操作能否得到通知，就可想而知了。

其它一些各种机器人

凡是需要读取区块数据，并且使用官网节点，并且使用的 get_ops_in_block API，那么都应该受此影响，但是那么卖票的机器人啥的不是用的这样的方式吧....

问题已经修复 & 思索

早晨重新测试，发现官网节点的这个问题已经恢复正常。
这算是个非常好的消息吧，我的懒人大法也再次立功了。

小小API，看起来作用微乎其微，但是一旦出故障，我们才发现它居然这么重要。
另外，从这个API导致点赞机器人失效、以及steemdata数据库内容缺失、以及可能引发的卖票机器人收钱不卖票，让我不禁思索是否该过度依赖API，但是不依赖API还能依赖啥呢？😀 或者该保持充分怀疑的态度，一旦API出错有各种补救措施，是不是有些杞人忧天的感觉呢？尽管天塌了一次，还会再次塌嘛？想的有点多了，哈哈

---

感谢阅读 / Thank you for reading.
欢迎upvote、resteem以及 following me @oflyhigh 😎