バグ #697
完了
Naoto Kawahara さんが10年以上前に追加.
約10年前に更新.
説明
ユーザをリムる（フォロー解除）していると，mikutterが落ちる場合がある．
自分のユーザペインのfollowタブから各ユーザペインを開き，ユーザのプロフィールタブからフォロー解除をするときの動作を一連の流れとして．
1.ユーザを開く
2.解除ボタンを押す
とすると．
1.ユーザを開く
2.解除ボタンを押す
3.1に戻る．
2のタイミングでmikutterが落ちる場合がある
再現性のために複数回試行したが，最終的にログは残せなかったので試行の結果を報告する．
- 再現性の確認のための試行
##0. （現象発生）何人かフォロー解除すると，mikutterが落ちる．
- 解除，複数人目でまたmikutterが落ちる．
- 15人目でmikutterが落ちる．
- --debug で起動． 30人""解除""してもmikutter落ちずログ入手できず
正直3回目あたりまで，フォロー解除がトリガーだと思ってなくて，何度もログが残らない試行を繰り返してしまった．
ログ無しで申し訳ないです．
- 関係ないこと？
あとこのチケットで報告すべき内容ではないのかもしれませんが，
フォロー解除をしてmikutterを再起動した時にフォロー数は更新されても，
followタブから解除した人が消えませんね．
人と人との繋がりに感謝！ってことでしょうか >< 勉強します．
こちらでもデバッグモード有効・無効状態でそれぞれ20回程度、同じユーザを何度もフォロー・アンフォローを繰り返すことを試行してみましたが、特に問題は発生しませんでした。流石に15アカウントとなるとテスト用のアカウントを用意するのが難しいです。
アンフォローしたユーザは、15アカウント別々のアカウントだったのでしょうか
クラッシュ時、クラッシュレポートを送信できなかったでしょうか。
また、Segmentation Faultなど、mikutterと直接関係ない要因でクラッシュした可能性はありますか。
関係ないこと？
あとこのチケットで報告すべき内容ではないのかもしれませんが，
フォロー解除をしてmikutterを再起動した時にフォロー数は更新されても，
followタブから解除した人が消えませんね．
仕様です。
mikutterは起動時、一部を除いては実際にはAPIリクエストを発行せず、最後に得たレスポンスキャッシュを使います。フォロイー・フォロワーは最初キャッシュを用い、次のフォロイー・フォロワーリスト更新時に実際にAPIリクエストを発行します。アンフォローしてからフォロイーリストを取得する前に終了した場合、そのような挙動になります。
この挙動についてはチケット化する段階にはありませんが幾つか改善策を検討していて、早ければ3.1にて変更が加わる予定です。
バージョン3.0.1です。
仕様の件了解しました。
アンフォローしたメンバですが、全て別々のアカウントです(このテストを始めてフォローを150人以上解除しました。
クラッシュ時、毎回クラッシュレポートは発行できませんでした。
Segmentation fault...知らない子ですね。
mikutter起動直後で起きているのであまり関係ないと考えています。
こちらの環境で一度も再現できておらず手掛かりもないので、30日経過して特に問題が再現できなければ、一旦別の問題だったということでチケットをクローズし、なにか分かったらまたチケットを作ってもらうという形にしたいです。
他の形式にエクスポート: Atom
PDF
